Boxes are good things. We use them when we move to keep our stuff with our other stuff. We use them when we’re not moving to keep our other stuff away from our stuff. We use them daily to keep the nasty gremlins (the furry four legged kind that meow all the time and the short two legged kind that still like to push buttons and then ask “what does this button do?”) away from our expense stuff that make up the guts to our computers. We even live in “boxes” to keep the cold out (or in) and the rain off our heads. Boxes tend to be rather good things.
Boxing software is a good thing. Box your project requirements, specs, work-flows, design drafts, and everything else you can put in a box, as long as that box is an 8.5x11 inch piece of plain white paper stapled or paper-clipped to a bunch more like it. Box your project itself with some sort structure/process even if that process is organized chaos, at least it has a definition at that point. Boxing software tends to be a rather good thing.
If boxes are such good things on their own and boxing software, or software projects in particular, is typically a good thing, it should stand to reason(*) boxing thought would be a good thing, right? Let me give you an example of why this is a very bad thing…
I work for a fairly large corporation developing a next generation business software system. This corporation has been around for a long time and shows no signs of slowing down or faltering in any way in the foreseeable future. This company has more people than I care to count dedicated to software development (more than it needs really, but that’s another story for another day). They do a very good job of making sure the project has enough resources of all kinds to succeed. They really do the “IT thing” right.
So where’s the horror story in there? It’s buried between the third and fourth sentences and reads something like this, “they don’t think beyond the box they already live in.” The reality of the company is that almost every business person in the company doesn’t want to think beyond what they already have. The majority of the projects the company is working on, from my perspective, is a re-write of an existing application in newer technologies doing a few more things. A few projects have gone far beyond this hurdle and are really treading new ground in the areas of functionality, speed, flexibility, etc. But none of that matters one bit for the lack of one thing.
Of all the projects the company is working on, the two most important systems it has in development are being driven by requirements summed up in this way, “copy the old one.” That’s it. Copy the old system. This thought process goes from end-to-end in these two projects. And despite the fact that these systems are top-tier (client facing) and built upon vastly superior re-writes of the middle-tier systems those re-writes are replacing, the end result system will probably do less than their predecessors did almost 10 years ago.
The company is entirely unwilling to try and find a better way. They see what they have today and that is what they want tomorrow. They view it as “if it ain’t broke, don’t fix it” which is just fine, except it’s broke and they don’t want to fix it. For years the company has locked itself into training its employee’s thought processes around the broken functionality of these two systems and now that they have the opportunity to break away from that and finally forge new ground, they’re so boxed into their current thought patterns that nothing outside of that makes sense.
Now for some explanations of all that. First, I know that there is a huge fallacy near the beginning of the article, that’s the whole point of the article, get over it. Second, I know that I’m just a low-on-the-totem-pole programmer with zero business knowledge compared to the folks driving this – if you don’t see the hidden message, you’re on the outside and you’re “the business,” sorry.
