There are always these articles where someone attempts to create a drawn out metaphor for something based on similarities to something unrelated… how software dev is like motorcycle maintenance (Zen and the Art of Motorcycle Maintenance) or like a restaurant (an article someone forwarded me on how Gordon Ramsay’s Kitchen Nightmares was likened to software development). Here’s a post about how software ISN’T like something. Software development isn’t like a hamburger factory (by which I mean McDonald’s or Burger King).
Imagine it, there you are a fresh-faced kid just out to make a few bucks so you can fill the gas tank of your cruddy Gremlin (thanks to Wayne’s World for immortalizing the epitome of the I-still-live-in-my-parent’s-basement vehicle) and take your girlfriend to the movies. Anyway, I digress… while you’re standing there blissfully day-dreaming about the aforementioned girl an order comes in for you to make a hamburger. You’ve gotten about 63 seconds of training on how to assemble a burger the Burger Factory way. In fact, it’s on an 8 1/2 x 11 inch laminated job aid with little pictures and circles and arrows describing what each picture is. You dutifully place down the wax paper wrapper, orient the bottom bun in the prescribed circle on the wrapper, slap on a wafer-thin patty, three pickles, a squirt of ketchup and mustard and plop on the top bun half. It’s a masterpiece of understatement! You glance up at the proper wrapping technique on your job aid and fold that 500 calorie delight up nice and tight. Job well done. Frankly, the 63 seconds of training doesn’t matter – the job aids, error proofing (note the nice little circle on the wax paper so you know exactly where to put the bun) and general familiarity assures us that you are now the world’s most complicated robot.
It does make me wonder why all those employees haven’t been replaced by robots, by the way. It’d probably be the coolest thing to walk into an almost totally unmanned fast-food joint and other than maybe interacting with a cashier, there isn’t a soul in there. We’ve seen via the supermarket that we can mostly get rid of the cashiers too and it has the bonus of not worrying that the robot might spit on your burger…
Alas, that is not my point. So, you’ve managed to make one burger. It’s a nice repeatable process right? Building on that last scenario, another order comes in for a burger. This time, you plop down the wax paper wrapper and drop on the bottom bun. But things have changed! The bun is bigger and it’s square! The patty is still round, and you’re relieved that ketchup and mustard still come out of their respective containers. You drop on the square top and do your best to wrap up the ill-fitting bun in the standard wrapper.
Next order: The wax paper wrapper is suddenly made of metal – and I don’t mean flimsy aluminum foil. It’s a hefty 1/16th of an inch thick. Buns are still square, but they’re significantly bigger yet. You have to place about four patties on the bun just to get reasonable coverage and the ketchup jar now spews mayonnaise.
What the heck is going on here? Your job aids are useless. They don’t have a step for dealing with hefty metal plates instead of wax wrappers and where the heck is the ketchup? Still, you put on the bun top and at least if someone took a quick glance at it they might conclude that this is indeed still a burger.
Thank god this doesn’t happen to you in real life. Working at Burger Factory would be a challenging experience every day. How could you expect a minimally trained teenager to deal with constantly changing inputs? And yet, this is the life of software development. Every “burger” you make developing software affects your ability to make the next “burger.” The system you are trying to work on changes. What once was a truth about the way the software was designed is suddenly just a fading memory of the core architecture that some well intentioned but relatively incompetent software developer violated.
It is an enormous frustration to anyone attempting to improve software development processes. There’s no repeatability because the act of working on the system is destructive. While I do mean that many poor-to-mediocre software developers do a lot of harm to the system even good software developers destroy the former truths about the system simply by enhancing it. Documents about the system become outdated or document half-truths. You’re lucky if you have documents in the first place. The only thing you can trust about the system is what it does right now and you can only truly know by looking at the code.
And this is what really frustrates me. When I watch people approach a Six Sigma project in the software world, it’s like watching a full-grown dog try and run under the chair legs like when he was a puppy. It is just bad for all involved – upturned chairs and a dog with a headache and a confused look on his face. I’m certain this is where significant distrust of Six Sigma becomes well justified. How frustrating is it for all involved that you can’t find a nice correlation between pretty much any factor and the resulting output – good or bad software. It still appears to be entirely an art.
It cannot be reasonably called software engineering if it isn’t a science. I think at this point two realities have to be accepted. One, laymen don’t understand software and so treat it as if it was as pliable as silly putty. You wouldn’t reasonably drive a bulldozer through the front door of your house and expect it to still be standing afterwards and yet metaphorically this is what people do with software every day. “Hey, I know I told you that I’d only be running about 1000 records through your tool each week, but I tried 10,000,000,000 and it’s too slow!” Two, process improvement people think software development is a science and not an art. I envision this as being on the two worst ends of a possible spectrum. First off we have people who think that anything done in software is free, that all software is easy to change and “what’s the big deal that I broke your core assumption about all the data coming into the system would have a unique identifier. So what if I reused some IDs?” On the other end we have people trying to help a company meet those crazy expectations of the customer saying “every time you change software, just follow this handy job aid and… what?!? What do you mean the buns are now square instead of round? My job aid shows round buns!” And software is really at neither end of the spectrum. It doesn’t just do as a I wish but yet isn’t created rigidly and predictably.
Let’s reset some expectations that created the above realities. Software development (for the moment) is at best a methodology, not a process. The difference is that a methodology is the hand-wavy this-is-what-we-kinda-sorta-do-except-when-we-don’t where process is we do steps a, b, c and d all the time, every time. It’s a spectrum, of course, but you get the idea. There is some point I think people could reasonably pick out where you’d say this is more descriptive (methodology) of what you do rather than prescriptive (process).
That said, I asked a master black belt at one point what the best tools were for dealing with this lack of repeatability. Needless to say, the answer was not satisfactory. Six Sigma doesn’t have good tools or techniques for this space and solutions needs to be made.
Secondly, customers need to suffer to understand real costs of software development. I’m thinking that every time a customer (or your manager who wants to get promoted and knows that the best way to get promoted is to fulfill every crazy customer request) asks you for a new feature you should be entitled to extract the cost somehow. If you were building a house and you had all the walls up and the roof on and then you thought “hey, I think I’d like a third story on my house”, I’m certain without anything telling you that it was going to hurt you where it counts. You probably should have thought of that earlier.
The thing is, we don’t build software like we build houses. Sometimes something that would seem very difficult under most circumstances works itself out quite nicely because of your particular design. Other times, something really innocent sounding shatters the foundation of your work. Anyway, it doesn’t hurt the customer in the same way it would if said customer was building his or her own house. I think software developers need either a small mallet or perhaps a taser or something to impart the appropriate level of understanding.
I mean really, why is it that people just accept that software requirements change? (NOTE: I had to come back and edit this rant after I let my boss read my blog site. Thank god she didn’t think I was crazy). Personally I think just because software requirements is a methodology doesn’t mean you couldn’t get requirements right the first time. Being loosely defined doesn’t mean poorly done. That said, the cost of such up-front quality would probably be enormous and not worth it. But what is missing is that people don’t have a sense of scale when it comes to requirements changes in software. Frankly, after the walls and roof of the house are up, some things will be easy to change and some things are going to really suck. All changes are not equal and the same is true with software dev. The problem is, people don’t recognize it in the same way as we do with homes. Certainly you can guess that if the walls haven’t been painted asking for a different paint color is not a horror. But software has none of those common features, so it is hard to say when a change will be easy or difficult. A lack of perspective is an unfortunate reality. Further complicating this situation is your customer had experiences with other developers who, because of their design choices, were able to make some changes easily that are difficult for you to make. On the flip side, every house you customer had built in their life was constrained by the same laws of physics. It makes things a lot easier to explain if the house will fall down as a result of a requirement change.
“Managing expectations”, “under-promise and over-deliver”. These are all reasonable ways of dealing with the reality of customers lack of understanding. And yet, I think software developers and their management do the most disservice to themselves by not having their own sense about how difficult a change would be.
It’s probably not the most coherent rant, but the point is this: from a process improvement methodology we cannot approach the problem like we are dealing with repeatable widgets. Software dev pretty much never makes the same thing twice. So let’s get over it and find a new path which needs new tools to predict success. And frankly, I think if we can deal with our own realities then the customer lack of reality problem (though annoying) will fall into place. Alas, I have no answers… I’m going to get some though, I hope. My real job kind of depends on it. 
