Steve Hebert's Development Blog

June 2005 - Posts

• pdc quandry

  I entered the "blog to the pdc" competition last night but now I'm wondering about the gamble this involves.  If I don't buy a ticket now, I risk the conference selling out.  But then I'm potentially out an additional 2k for travel and hotel expenses in addition to the $1500 for the conference if I lose the competition. I guess if I don't win and I don't want to bite off the travel and lodging expenses, I can sell the ticket on eBay.  So that begs the question - is the conference attendance ticket refundable or transferrable? Posted Jun 30 2005, 08:42 AM by shebert with 5 comment(s) Filed under: Development

• Blogging my way to the PDC -or- overdone british literary adaptations

  <-- Click on the logo to vote for my entry! <crosses fingers> Here's my entry... </crosses fingers> PDC will be my first major conference in several years and I look forward to blogging about it.  If I win I'll start blogging about the journey right away - starting with the winning announcement to making arrangements and all the way through to the flight home.  I'll blog the bits I learn and bring my laptop for doing so.  I'll also use the time to meet up with other bloggers and finally put faces to the names - and take every opportunity to network and gather swag. I'm really looking forward to all of the sessions surrounding Visual Studio 2005 and Sql Server 2005 along with a closeup view of the changes to the Compact Framework.  I'll also be able to take this information and put it to use right away.  I'll also take my video camera and post snippets that are the most interesting.  And for a gag I think perhaps I'll host the "worst PBA contest" - that's conference speak for "Pathetic Bid for Attention". This is where someone gets up and tries to stump the presenter with some esoteric code bit that has nothing to do with the presention.  It has to be followed with a few sighs from the crowd to be considered a true PBA. Finally, as part of the CodeBetter community, if someone from Microsoft brings me up on stage I'll launch a couple of extremely rare "Code Better on LSD**" t-shirts into the crowd.   ** LSD stands for Lean Software Development And finally as my wife and I are expecting twins in January this might be the last conference chance for a while.  I figured I'd throw together a little poem - I guess you could say it was influenced by a popular children's book.   You can think up some code. That’s what you can do. You can think about scripting or ASP2…   You can think about Team Server You can think about a link That takes you to Ajax… Oh the THINKS you can think!   Oh the thinks you can think up if only you try!   If you try, You can think up A blogger going by.   And you don’t have to stop. You can think about SOP. SOP. SOP. Beautiful SOP. Beautiful SOP with abstractions on top.   You can think about cryptography You can think about API  (rhymes with ‘happy’) You can wonder to yourself why they never called it CrAPI.    Think first of LA And then think of generics Think of conference food And then grow hysteric.   Think, Think and wonder. Wonder and think. How much water Can thousands of developers drink?    Or think of Scoble the Bloggerman Who scatters the hype Several times a day And never on skype   Oh, There are so many thinks a thinker can think Would you dare stump the expert Or just have a drink?   And you can wonder… How much C will be left In version 3     Oh the thinks you can think!   Think! You can think Any think that you wish    Think of a race On C# On 64 bits With a fish   Think of the sessions Think of PDC Think about blogging And the role there for me!   Think left and think right Think low and think high Think of sending me to PDC It’s easy if you try!   Posted Jun 30 2005, 12:49 AM by shebert with 4 comment(s)

• Accessing a project-level file at runtime

  Here's the code for accessing a physical file (i.e. jpg, gif, etc.) that is referenced in the solution. I run into this bit of code every once in a while but never frequently enough to remember it off the top of my head... Stream stream=Assembly.GetExecutingAssembly().GetManifestResourceStream("[project].[path].[file]"); Posted Jun 29 2005, 05:37 PM by shebert with 4 comment(s)

• Component Search: visio-like functionality

  I'm looking for a .Net WinForms component that provides some form of Visio-like functionality (including object relationships) without requiring Visio on the machine.  I'm not sure if something like this even exists, but if you've used it/seen it, then I'd love to hear about it. Posted Jun 28 2005, 03:03 PM by shebert with 4 comment(s)

• Process Certification discussion

  With all the talk about certifications like CMM over the past couple of years, Mary Poppendieck's article titled "Toward a New Definition of Maturity" really hits the mark. She discusses the potential faults of decomposing large tasks into separate, compartmentalized sub-tasks.  As with the waterfall process, "optimization of the parts has a tendency to sub-optimize the whole."  Tying these pieces back to Lean Software Development and the earlier post I wrote on push- vs. pull-based development has been a lot of fun.  I've had some great conversations on the topic and one in particular with John Maher at Synchrono around project organization - what it means to the entire dev process and how multiple, interrelated projects can be managed as a single comprehensive plan to avoid churning (can you say Sql2k5/Whidbey?).  I could put out several blog entries on that email alone. I'll be posting more shortly. Everyone has given me a lot to think about... thank you! Posted Jun 28 2005, 01:19 PM by shebert with no comments Filed under: Development

• an open-source Constraint Solver?

  Has anyone come across an open-source / free Constraint Solver that maintains graphical representations of connections between objects (much like Visio).  I'm digging for a solution that works witin the .Net framework as an assembly or C# code.  Worst-case, I could always convert from VB.NET or J#, but I'd rather get one that lives and breathes C#. Posted Jun 28 2005, 10:35 AM by shebert with 1 comment(s) Filed under: Development

• office humor: "everybody back to standing on our heads"

  This is off-topic, but when someone walks out of a meeting and says "ok, everybody back to standing on our heads" you'll know what they mean.  A guy dies and is sent to Hell. Satan meets him, shows him doors to three rooms, and says he must choose one to spend eternity in. In the first room, people are standing in *** up to their chest. The guy says "no, let me see the next room." In the second room, people are standing with *** up to their necks. Guy says no again. Finally, Satan opens the door to the third room. People are sitting down, drinking coffee and eating danish pastries with *** only up to their ankles. The guy says, "I pick this room." Satan says okay and starts to leave, and the guy sits down and starts pouring some coffee. On the way out Satan yells, "O.K., coffee break's over. Everyone back to standing on your heads!"   Posted Jun 27 2005, 07:30 PM by shebert with 1 comment(s)

• Six Sigma on LSD: clarity strikes

  Mary Poppendieck has an article that appeared in "People on Projects" explaining the combining of Six Sigma and Lean.  This is a great read. The last section titled "Delayed Commitment" talks to the role of testing as the heartbeat of the process in my post discussing push vs. pull-based development. Posted Jun 24 2005, 09:59 AM by shebert with no comments Filed under: Development

• Getting mono::live running on VPC

  I ran into some problems getting the mono::live boot cd running under VPC until I came across a blog post by Christoph Wille.  This is a nice writeup and addresses the problem quickly. Posted Jun 24 2005, 09:25 AM by shebert with 4 comment(s) Filed under: Development, Note to Self

• Lean Software Development: differentiating push- and pull-based development

  I was reading a white paper over at Realization.com and a thought hit me regarding lean vs. conventional development. Backing up a moment, perhaps I need to explain some of my reservations toward conventional waterfall development.  I've always felt that projects driven by the waterfall approach are fear-driven - fear of the developer and fear of the development team producing something the business doesn't want.  However, waterfall often times doesn't even protect you from that fear - market pressures exerted during the development phase are forcibly ignored by the project manager who is guarding against scope creep for fear of jeopardizing the previously committed schedule. This makes me believe my fear theory is wrong.  Waterfall is also capable of driving specifications to the nth degree before development begins and many are outdated by the time they are saved in some document repository. Worse yet, waterfall taken to the extreme is capable of distilling context out of the specifications which can lead to developers making poor implementation decisions.  After reading the white-paper titled "What should multi-project operations focus on: Resource Utilization or Cycle-Time?" my entire attitude toward waterfall completely changed. The article states that the primary operating assumption in traditional, waterfall development is "not enough resources."  That deserves repeating... The primary operating assumption in traditional, waterfall development is "not enough resources". Take a moment and consider the waterfall project.  The entire process is usually driven by a master Microsoft Project template (or some other tool from that software category) where tasks are broken down, dependencies stated and ultimately resources are assigned - everything drives to assigning resources. The project manager's primary focus is getting and holding onto resources with every grasp of energy.  Good project managers will protect their people from outside interruptions and getting time taken up by other projects - they are protecting their project.  But what if their greatest battle is actually fighting the schedule they've created?  I contend this happens all the time. Going back to the Realization whitepaper, they state the traditional operating assumption is "not enough resources".  They contrast this with a lean approach that states "reducing the cycle time of projects will increase overall throughput".  They further contrast the differences by stating that traditional operations set aggressive resource utilization targets for the resource while lean operations set aggressive cycle time reduction targets to ensure that there is no room for Parkinson's Law in the project. This becomes clearer on how lean differentiates when you read Darrell's LSD principles.  When you drill down on the approach you can see that waterfall projects are push-based while lean is pull-based.  Pull based is fundamentally different and merits some discussion. If you look at lean from a manufacturing standpoint and compare it to software - I see a couple of concepts that are critical. This whitepaper from Synchrono is particularly useful in this discussion from the first three pages by introducing the following concepts: the pacemaker and takt time. The pacemaker is the constraining resource (development) and all focus is directed on delivering continuous flow to the pacemaker.  This continuous flow includes inputs such as specification writing, sample data generation and anything else that feeds into the development process. This continuous flow also includes the output - which is code that is handed to resting. Meanwhile, we also have the concept of takt time.  Takt comes from the German language and means meter - as in musical meter.  Takt time is the rate at which the market consumes the product coming from our pacemaker. In development terms, takt time is driven by testing.  For this process to be effective, testing is continuously building the product, testing it and providing feedback to development with a 24 hour turnaround which is referred to as the heartbeat in lean terms.  Now developers are receiving feedback immediately after coding and not waiting 3-4 months before testing gets involved.  This takes the whole process a step beyond Test Driven Development - not replacing it, but further enhancing the quality of feedback to development. Since we are no longer driving off of a static schedule and development is pulling tasks to be completed based on triaging the highest priority issues we can see a number of capabilities that play to Darrell's points mentioned earlier.  We can now "decide as late as possible" since specifications can be written at the last possible moment provided they don't violate the continuous feed to development.  The longer we wait on specifications, the better those specifications will be by adjusting to realities such as market shifts during the development process.  Here's the best part, I can now respond mid-cycle to a new requirement!  New specifications can be driven to completion and prioritized on development's "to-do" list and handled in the normal process - it's simply a question of evaluating the size of the task and deciding when it needs to be released.  As opposed to waterfall, the entire process and schedule doesn't need to be rebooted to accomodate what was formerly considered a major interruption.  Finally, if I need to push the project out sooner based on customer requirements, I can choose an arbitrary cut-point at any time and deliver the product with minimal interruption.  In reality, the concept of "three-month cycles" or "six-month cycles" are now truly arbitrary and have no meaning or value beyond the marketing/planning benefits because development is now focused on a 24-hour cycle. I previously posed the question "is Lean just a rehash of Agile?"  I believe the answer is a resounding 'no'.  While Agile&XP focus on making changes starting with the programmer, lean focuses on the management process and drives down to the programmer.  Lean cannot exist without Agile/XP approaches while Agile/XP can become much more effective with Lean. There are a number of traits you have to consider in a product used to drive this project such as managing sequential processes (called gating).  A gating capability can even allow you to coordinate multiple projects under one plan (try doing that on a complex project set using MS Project!).  There are also architectural issues that must be addressed along with programmer skills.  I'll leave those discussions for another blog entry.   Posted Jun 23 2005, 10:00 PM by shebert with 10 comment(s) Filed under: Development

• I attended my first CVNUG meeting last night...

  I drove over to Eau Claire, WI last night to attend the Chippewa Valley .Net Users Group that I blogged about before.  This was the first meeting of theirs that I attended.  Last night's speaker was Rocky Lhotka and he discussed his CSLA framework. His presentation was great and he detailed the history leading up to CSLA and also explained the implementation strengths.  I particularly enjoyed how he sees its usage in relation to layering. Dan and Doug who started the group were very helpful and a pleasure to talk to. They have an extensive book library that members can check out and there were lots of things they handed out after the meeting.  I have to say I thoroughly enjoyed it.  This is a small group and it gives you a chance to talk to the presenter and network with others in the area very easily.  If you are anywhere within an hour or two of the Eau Claire area, you need to check this out. Posted Jun 22 2005, 05:41 PM by shebert with no comments Filed under: Development

• Agile == Lean?

  I’m working on a project right now that is using MS Project to delegate the tasks being done.  I haven’t been on a project like this for six years, but it brings me back to a couple of points especially after reading Lean Software Development by Mary and Tom Poppendieck. The relationship between Lean Manufacturing and Agile are more striking than just applying a new name to Agile.   Lean manufacturing differentiates between push-based and pull-based systems.  In the software world, MS Project is push-based – plan every step ahead of time and execute to plan. Agile/XP interates on building the highest priority remaining features – this is pull-based. Pull-based allows for on-the-fly adjustments to be made. The resulting difference between the two is a serialized development approach with push-based systems and a concurrent approach with Agile/XP. Agile values working software over comprehensive documentation and responding to change over following a plan. As Alistair Cockburn states it, "requirements can be imperfect, design documents and project plans can be out of date, yet the project can still succeed by applying such principles as communication and community."   These thoughts drive two points for me:   Traditional software development is push-based, and if you understand how push-based manufacturing systems work you will quickly understand why basing software planning on this type of operation fails 9 times out of 10. Documentation is a balancing act to provide the best investment of time.  Too much documentation is useless as it becomes outdated – at which point it’s not only useless but slows the team down.  An emphasis on communication and test-driven development enable a software team to respond to the pressures of a concurrent software approach.  So given these points, is Agile just an implementation of a lean methodology?  I was initially skeptical of the Poppendieck’s book, but the similarities are more and more startling as I’m getting a harder look at “the other side”.  Posted Jun 21 2005, 09:10 AM by shebert with 15 comment(s) Filed under: Development

• Implementing TDD in a large environment

  All the books I've seen on TDD focus on rolling out TDD to small development teams.  What about the scenarios where people are rolling out across multiple projects with large number of developers.  How about rolling out across multiple platforms?  Has anyone run across these types of rollouts and what works?  I've generally seen that starting with shared, pilot projects works well and transitioning other developers into the fold with paired programming. It all comes back to a group of evangelists driving the implementations across an organization.  Has anyone tried this or other approaches?  I'd love to hear about it! Posted Jun 20 2005, 02:07 PM by shebert with 3 comment(s) Filed under: Development

• Sql Server Service Broker Challenge

  Here's a reminder to myself... I need to get the June CTP and connect using service broker to Rushi Desai's Broker Challenge... Posted Jun 16 2005, 03:26 PM by shebert with 1 comment(s) Filed under: Development, Note to Self

• My Code Talking article is now online...

  My Code-Talking article is now online and currently listed on the CodeBetter.Com homepage.  This is the first in a series of articles.  The article discusses the role of code-talking on teams.  How much does your team code-talk?  What effect does this have on  your development process?  Check it out and let me know! I considered naming it 'funky walker, code talker' but figured the MadTV reference would be a little too vague... Posted Jun 15 2005, 06:39 AM by shebert with no comments Filed under: Development