Big Faceless System, Version 5

Dietrich Kappe, Monday, November 30, 2009 @ 5:45 am

photo credit: Daquella manera

When you're in software development you sometimes get called in via the Bat Signal -- a project is going sideways and management feels they need more bodies or different bodies to get the thing back on track. For a while now we have turned down "gasoline" work (see The Mythical Man Month on throwing gasoline on the fire by adding more developers) but still do a fair amount of toxic software project remediation.

In one particular case the system in question was several months late and substantially over budget. After a few days of reading documents, interviewing developers and meeting with stakeholders, one thing stood out. This system -- we'll call it "Cool Beans" -- was in fact "Cool Beans 5," i.e. the fifth version of this system. I asked the product manager the obvious question: "What was wrong with versions one through four?"

He told me that none of them had ever been adopted by the business units they were built for and that it was concluded each time that the technology was to blame. This time they were writing a web application, so all of their problems should be solved.

About a week later it was clear to me that the motivation for the latest incarnation of "Cool Beans" was that central corporate management wanted a way to enforce workflow and reporting on various semi-autonomous offices around the country. All of the previous systems had been heavy on prescriptive workflow and extensive reporting -- for the benefit of corporate management -- and offered precious little to the actual users of the system. No wonder they had never been adopted.

Why Companies are Bad at Developing Software

When we talk about the shortcomings of corporate software development processes, we often focus on the difference between waterfall and agile. That comparison certainly still holds, but there are other, more critical factors that bend these projects toward failure.

In the above case, the failing was an all too common one: they had the wrong people giving requirements for the system. Instead of asking the actual end users what would help them do their jobs, they instead had someone from corporate designing a system to enforce a new way of working, one that probably didn't make much sense or work for the end users.

That's why you see lots of three, four, five and so on versions of the same system in corporate environments -- they keep making the same mistake of having the wrong people give requirements. On the one hand it may seem obvious, but I've personally seen this mistake committed more than two dozen times in a variety of industries.

Now what's true for internal company systems is also true for public-facing software. If you don't let the user tell you what they want -- if you substitute your own judgement for that of your customers-- you run the risk of building a system based on your misunderstanding of their needs.

It may seem inconvenient and untidy to have so many outsiders in your software development project, but what you may see as untidy results in actual end users modifying your product vision and concept into something that people will actually want. Yes, the process can be messy, but there are ways to deal with that (more later on how to use the practices of User Experience Design to make the process of requirement gathering from end users go more smoothly).

So, if you are developing version 1, make sure you get it right and not wait for version 5; get the right people in the room from the beginning and involve the end users.

Related posts:

1. The Incredible Rising Version Number
2. Digging a Hole and Covering it with Leaves — The Software Development Version
3. Rails Testing Frequently Asked Questions — The Non-Code Version
4. Open Office (Not The Software Version)
5. jQuery fade-in spoiler revealer: The failsafe, progressively enhanced version

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I’ve hit that problem so many times in the past it’s unreal. For the first time ever I’ve found myself working for a company where we have a completely different (and just as absurd) problem:
   Lack of specifications.
   Not only can we not get any specifications out of the eventual end users, we can’t get any out of management.
   “Go build one of these systems, make sure it integrates with xxx” “Sure, what do you want it to do?” *queue silence and the odd subtle hint that we should just go and make it anyway and make it do whatever we think it should do*

   Occasionally we’ll get the other problem, a fairly reasonable spec that after a few weeks of work, then starts changing every day, negating 90% of the previous work done on it.

   Comment by Hypo, Monday, November 30, 2009 @ 8:48 am

Leave a comment