Archive for September, 2006

Software Development is Sometimes Sorta Like… Building a House

Published by scott September 28th, 2006 in Software Development is Sometimes Sorta Like. 0 Comments

This is the first in a series. Software development is software development, it has its own unique challenges and it is not exactly like building a house or any of the other things that I will be comparing it to. But there are analogies that can be drawn, and I think they can be constructive, or at the very least, entertaining. So here we go.

Software Development is Sometimes Sorta Like Building a House

  • If you put the drywall up before the plumbing is in, you will tear down the drywall to put the plumbing in.
    • It is hard to envision what the final house will be like until the drywall is up.
    • You may be eager to put up the drywall to feel what the final product will be like.
    • This desire will be strongest if this is your first house.
    • If this is your 500th house, you will fire anybody who puts up drywall before the plumbing is in.
    • Maybe you could attach the drywall temporarily with easy-remove attachments. The drywall will get damaged, and the easy-to-remove attachments will be in the final house. The ultimate owner of the house will not be happy when his ceiling falls on his head while he is reading the Sunday paper.
  • Every house is unique. Every house is the same.
    • If you are in charge of building a house, there have been milliions built just like it.
    • The house you are building is unique. It may even be a one of a kind design envisioned by a famous architecture and design firm.
    • No matter how unique your house is, there are expectations for it
      • The house will not fall down
      • All doors will close tightly and reliably
      • The electrical system will be sufficient and meet local standards and codes
      • The house will not be in danger of catching fire during normal use
      • The house will be visually appealing
      • The front door will be on the front
      • The garage door will open automatically
    • If you keep enumerating the requirements for your home, you will find that this construction project is almost exactly like every home ever built.
  • There are companies that build homes like this every day.
    • Some of them are wildly successful, profitable, and have highly satisfied customers.
    • Some of them go bankrupt, get sued, and have dissatisfied customers.
    • The successful companies do things differently than the unsuccessful companies.
    • What the successful companies do is usually no secret.
      • It is sometimes hard to believe that what they do leads to their success.
      • It is even harder to have the discipline to do these things that lead to repeatable success, unless you’ve done it before and have experienced the rewards.
      • The people who run bankrupt companies with dissatisfied customers that sue will tell you that the discipline followed by the successful companies is a load of garbage.
      • There may be successful companies that tell you what their successful competitors do is a wasteful load of garbage. Go work for these naysayers and you will find that they are in fact quite disciplined, follow many of the same techniques, but call those techniques by different names or have integrated them so deeply into their culture that they don’t see them as methodology at all.
  • Building a house is like building a house
    • Building a house is not like building a skyscraper
    • Building a house is not like building a back yard shed
    • Building a house is not like building a diorama for your 4th grade daughter
  • You need blueprints to build a house
    • You can build a diorama for your 4th grade daughter in an afternoon with just an idea in your head
    • You can build a back yard shed in two afternoons if you follow very detailed instructions very carefully, if all of the pre-fabricated parts have been drilled exactly right, if the bolts to attach them together are all in the package, and if there are no mistakes in the instructions. If there are problems, you face at least a week delay (to wait for your next weekend of free time) and possibly 6 to 8 weeks delay (to wait for the manufacturer to ship the correct parts).
    • To build a skyscraper, you will need about 10 years. Of course you can’t build a skyscraper without blueprints. But you need much more.
      • It will take 2-3 years minimum to secure a location desireable enough for your skyscraper
      • It will take another year or two to work through the political process to allow your skyscraper to be built there
      • You may never secure the site, or the permission to build there, so your project might not ever get off the ground
      • You can do some things in parallel
        • The design of the building will take 2-3 years to finalize
        • The architecture and detailed blueprints will take a year or two or three
      • After 3 to 10 years you can start construction
        • Construction will take 2-3 years if all goes well
        • Construction will take much longer, or never complete, or be completed with major, expensive-to-fix errors if any of the up-front planning was insufficient.
        • Somebody very experienced needs to be in charge of this phase. One supply, labor, design, or implementation glitch can delay the entire project for months.
        • If this is your first house, and you realize it is a skyscraper, leave the building and go find a house to work on. You don’t want this skyscraper to fall over because of you. More likely it would just never get built, in which case you will have wasted 5 years of your life on nothing.
        • If anything major goes wrong, the investors will lose all of their profit and some or all of their capital, even if the construction finally completes and the building appears to be a success.
    • You can build a house in a year if you know what you’re doing
      • If you have built this kind of house before, you will have detailed blueprints with corrections
      • You will have reliable suppliers for the components you need
      • You will have a trusted labor force that can follow the blueprints exactly and on time
      • You will know your customers’ rational and irrational expectations and meet or exceed those expectations
      • If you’ve been at this a while, you can build 10 or 100 houses in a year, because you will have many corrected blueprints, many reliable suppliers, and a large trusted labor force, and every house is almost exactly the same as long as you are willing to say “no” to the customer when they ask for the front door to be on the roof.
    • You can’t build a house in a year without help if you’ve never done it before
      • You may find yourself tearing the drywall down to put in plumbing
      • Then tearing it down again to put in an electrical system
      • Then putting in space heaters and window-unit air conditioners because you forgot to put in a centrail air system and you don’t want to tear down the drywall again
      • Then calling in the professionals when the house sinks halfway into mud and starts itself on fire

If you are building a house without blueprints, if this is the first house you are building and you are expected to build it in one year and exceed your customer’s expectations and you are just starting to recruit workers and find suppliers, if your customer requests the front door to be on the roof, if it seems like you are expected to build a skyscraper with the budget of a house, if you are expected to assemble a shed in a weekend with no pre-fab parts, no bolts, and no foolproof step-by-step instructions… you are in trouble, and it’s obvious that you are in trouble and that you will not be able to achieve the goal as expected. You would say “no, I can’t, and you’re an idiot for asking” if presented with any of these challenges.

Software development is sometimes sorta like building a house.

Software Schedule Estimation Via Bullet Points

Published by scott September 22nd, 2006 in Eclectic Tech. 0 Comments

I don’t know the secret to accurate software schedule estimation, but I have a pretty good technique that is simple enough for anybody to do. With this technique, you will be able to estimate your software project schedules with the same accuracy as major software development houses, large corporations, and experienced consulting companies.

The process starts with a list of bullet points. This is similar to a “requirements list” but less formal, you can do it as bullets in Word or even individual lines of text in a simple text editor. Each bullet point should be 75 characters or less (a few characters will be added later as you will see).

No matter where you are in the project (early conceptual stages, initial planning stages, or even if development is fully ramped up and in progress) sit down with a blank list and start making single line entries, 75 characters or less, that describe the things that need to happen for the project to be completed.

Don’t limit it to product features, include mundane things like “buy new computer to replace the one that exploded”, and “hire new developers and get cubicles allocated”. As you can see, some of the items will be very specific (”buy new computer”) and some will be very broad (”hire new developers”). Try to keep each line focused on one thing - split “hire new developers and get cubicles allocated” into two items, “hire new developers” and “get cubicles allocated”.

After a while you’ll run out of things to put on the bullet list, or the list will get so long that you’ll begin to shake and cry uncontrollably. When either of these things happen, it’s time to stop.

Now, count the number of bullets. This is the number of days you’ll need until the next phase. When translating this to calendar days, make sure you leave out weekends. You will need the weekends anyway, but don’t include them in this number.

Let’s say you had 30 bullet points. This translates to exactly six weeks. For the next six weeks, work on the items on the bullet point list. When you complete one, put a “+” to the left of it. If you decide not to do one, put a “-” one next to it. For all of the other bullet points, leave them as they are - those are the ones that need to be worked on next. Note that even though we allocated one day per bullet point, this does not mean that each bullet point can or will be done in one day. The actual amount of time it takes to complete each bullet point depends entirely on the resources you have at your disposal. Do the best you can. Some bullet points won’t get done. Don’t worry, we’ve got that covered, as we’ll see in a bit.

Often, you will come across a bullet point that is really more than one task. Let’s say you had a bullet point that originally said “Implement user interface”. When you come upon that one, you won’t be able to just do it as-is. You’ll want to expand it out into some more bullet points. For example, “Implement user interface” might expand out to 50 more bullet points, itemizing the widgets that are needed, the various screens and menus that need to be designed, the visual styles that need to be determined, etc.

When you reach the end of the first phase, you will still have your bullet point list, but it will have been transformed. You need to clean it up at the end of each phase. Go through the list and remove all of the lines with “+” or “-” at the beginning of the line. Those have been addressed and you don’t need to ever think about them again until testing time. There will be quite a few bullet points from the start of Phase 1 that have not yet been addressed or thought about at all. That is ok, leave those on the list.

After you have cleaned out all of the addressed items, scan through the list including the newly expanded bullet points. No doubt some things will occur to you that weren’t on the first bullet point list, and are still not there. Add those to the list. Also, you may see some bullet points that can now be expanded out to more detail. Go ahead and expand those out now. As with Phase 1, keep doing this until you run out of ideas to add to the list, or until you begin to shake and cry uncontrollably.

Now it is time to start Phase 2. Count the number of bullet points that are on your cleaned up list and allocate one day per bullet point again. Let’s say you have 120 items on your list now. That is 24 weeks. Start into the new bullet point list exactly as you did with Phase 1. When an item is completed, mark it with a “+”. If you decide an item is not needed or will not be done, mark it with a “-”. If you find a bullet point that needs added detail, expand it into a new list of more detailed bullet points.

As you can probably tell, Phase 2 follows the exact same methodology as Phase 1. In fact, every phase follows this same approach. That is the beauty of this technique. Once you know the basic procedure, you know the whole methodology, and no special software is needed. In fact, this entire methodology can be implemented with a pad of paper and a pencil.

Eventually, the product will need to ship. The forces that determine the ship date of a product are typically beyond anybody’s control, no matter how powerful any individual person may be. You will typically have some early warning of when this date is, and you will need to allocate some time to fix any problems that exist with the software. Do the best you can. No doubt you’ll still be trying to implement items off your bullet point list during this time, so technically any testing you do will be invalid. Plan for some sort of automatic online updating system for the software after it ships.

And that’s about it! Unfortunately, this method doesn’t tell you the full schedule of the project on day 1. All you can say on Day 1 is when Phase 2 will start, and due to the unpretictability of each bullet point (some happen quickly, but most take longer than expected, and almost all of them expand into more bullet points), knowing when Phase 2 starts isn’t really much help. But it’s the best you can do, and it’s about as good as the best professionals can do. In fact, it’s better than a schedule that sets very specific dates in stone, because those kinds of schedules just make everyone shake and cry uncontrollably when they realize there is no way those dates can be met. With the bullet point approach, the shake-and-cry periods are planned out ahead of time and are expected, and so they are easier to deal with.

Am I serious? I started writing this partially to be funny, and partially to put down in words the actual approach that I use for software development. There are projects that I can schedule very well, but those projects are basically repeats of other projects I have done, using well understood technology and doing the exact same tasks as a very similar project that has already been successfully completed.

As the world of software matures, the number of repeat projects increases - this is the software industry’s version of building strip malls. If you’ve been doing it for a while, you know how long it takes to lay the grade, roll the pavement, and slap together the strip of shops. But often in software, there is some innovation required, so the project is more like building a spaceship that can also drive at highway speeds and travel waterways like a motorboat, with an outer skin that can display high resolution full color images and a life support system that includes the capability to manufacture cotton candy from sugar synthesized from molecules formed by shooting lasers at particles being accelerated in a 5-mile radius loop. These types of projects tend to be difficult to schedule, but the bullet-point list will get you as close as you can get to something reliable.

Oh, and we’re gonna need a killer stereo system in that thing. Add it to the list.

The True Meaning of Windows XP?

Published by scott September 14th, 2006 in Eclectic Tech. 4 Comments

I couldn’t sleep, so I broke out my laptop to work on some code that is rattling around in my brain. I had to cold boot Windows XP, since I had shut it completely down earlier to install some Windows updates.

It’s dark, it’s quiet, the black Windows XP loading screen glows dimly on my screen…

“XP” … it sounds so natural now. I run “XP”. Most of my machines have “XP”, a few have “2000″. These are brands, everybody knows them. But why XP?

It rolls off the tongue easily enough, it sounds professional, but as trademarks go, it’s not so great. A two-letter non-word isn’t the most defensible trademark. That doesn’t matter so much, obviously the XP brand has power…

Why those letters?

The loading bar zooms left to right, left to right, never giving off a hint of how much is left to go, just letting me know it is still working on it…

Did it really stand for “Windows Experience?” The 2001 Microsoft press release claims this is so, but that sounds pretty weak, way too meaningless… almost like a convenient answer to satiate those who are curious enough to ask…

What else… around 2001, “Extreme Programming” had quite a buzz going in the programming world, and that was always referred to as “XP”. Perhaps some engineers at Microsoft liked what XP stood for and thought that it represented what Windows XP had under the hood?

But that doesn’t make much sense either. Extreme Programming was something happening outside of Microsoft, and it seems unlikely that they would take on the nickname of someone else’s methodology as their product name…

The loading bar continues.. left to right… left to right… “I’m loading… don’t you worry about how much is left to go, I’m on it…” XP… XP… what could it be…

Or, as on the loading screen, lowercase xp… xp… p is the greek letter “rho” … hm… oh yeah and of course, x is chi… “c.r.” does that stand for anything? hmm… chi, rho… chi, rho…

CAIRO!!!!

Of course, Cairo!! A famous Microsoft codename originally used for Windows NT 4.0, but also used to describe a set of technologies that didn’t all make it into 4.0. Cairo was envisioned as the ultimate operating system, and an ambitious feature set was announced, much of which took longer than expected to complete. The remaining technologies that were originally targeted for Cairo were eventually added bit by bit to all of the versions of windows between Windows NT 4.0 and Windows XP… xp being the real Cairo.

All of those technologies are now in the ultimate operating system, XP… except, of course, for the object-based file system WinFS, originally annoucned for Cairo, and recently cancelled yet again for Vista. But that’s ok, I prefer plain old file systems that store and retrieve hunks of bytes, that has always worked well for me. Perhaps whoever chose the name XP decided that Windows XP was finally close enough to the Cairo vision to be called Chi-rho.

Ah, my machine has booted finally… my Windows chi-rho, cairo, xp machine… now, time to get to work. But, on second thought, I guess I have time to type up a blog entry before really digging in…

About

You are currently browsing the Red Mercury Labs weblog archives for the month September, 2006.

Longer entries are truncated. Click the headline of an entry to read it in its entirety.

Latest

RSS

Archives

Categories