“Measure Twice, Cut Once” by Andrew Gideon, CTO/VP

I’ve been writing software professionally since 1982. Over years of employment and education, I’ve learned a lot about how to build software well. Unfortunately, I’ve also learned a lot about how to fail. Some of the lessons I’ve learned along the way seem obvious. They should be obvious! Yet being obvious is apparently not enough. How many people reading this have regular and confirmed backups of all their important data. Their email? The videos of their children? Their medical records?

I’ve come to the belief that software development suffers from a problem of abstraction. A person can see a piece of wood, can feel the weight of a table, can admire the size and structure of a building. Software has no such physical representation, weight or apparent size. To most people, it is an invisible abstraction that only barely exists. That it represents a significant investment of man-hours or that it may rival or exceed the complexity of many physical projects is counter-intuitive to many.

Because software is something without apparent weight or physical heft, it tends to be seen as having no weight or heft. Because the complexity and size cannot be gazed upon, it is presumed to be simple and small. The end result: people think that software is easy. This causes unreasonable expectations of time and cost for projects.

Making the situation worse is that the increasing pace of ever-growing need for new software means a steady stream of new and inexperienced professionals. To use a metaphor, these are people that have become experienced in building log cabins. When asked to build a skyscraper, through no malice on their part they simply assume that they can scale up the techniques they use for building log cabins. If they know how to build a one-story building, they can just do the same thing 40 times for a 40 story building.

I’ve just caused all the architects and construction engineers in the audience to shudder and/or laugh.

Imagine being told to skip the design process, and immediately begin construction of a skyscraper. Imagine being someone that was going to be working or living in the resulting building. Yet this is precisely the situation in which too many businesses find themselves: using software that was put together like a log cabin, but which has the complexity and stability requirements of a skyscraper.

Through office politics and pressure, even those that know better can find themselves forced into this position. A person with whom I used to work recently had to show physical progress on a project despite the fact that there wasn’t yet a complete understanding of what the project was supposed to achieve. His bosses weren’t interested in the planning process, the analysis being done, or the plan for implementation being formed. Actual machines doing actual things were their only measure of progress.

It’s no wonder that his professional life includes so many emergency responses.

This problem is not insurmountable, but it does require some investment in education. We’ve a client forwhom we’ve been developing an ongoing project for a couple of years. The first few releases were painful. He expected things to be done immediately, and didn’t understand why we kept pestering him with question after question about how he wanted the software to behave. His idea is that we should just get the software working pretty close to how he operated his business, and then tweak as necessary. And the software should be done now.

But after a number of rather expensive tweaks for details he’d omitted, he began to understand that the more information we had about his business needs before we began, the better a job we could do in satisfying those needs.

Today, the process followed with this client is incredibly smooth.

Education is just as important on the other side. There is simply no way that we could produce software for his business if we weren’t willing to invest the time and effort in understanding his business. Too many people have a love for developing software but resist learning the businesses of our clients. But we cannot truly provide our best value unless we know and understand what the software we’re building is supposed to do.

Another example may be found in a new client of ours. This client had software for their web site developed by a firm in India. More than $120,000 later, they still lacked software that did what was wanted. The problem is apparently that nobody on the software development team actually understood what the client wanted. There was a project manager responsible for progress being made, but nobody responsible for the direction of that progress. In a way, it was like that old cartoon of the railroad lines from the Atlantic and Pacific coasts meeting in the mid-United States…a few meters offset from one another. Lots of trackthat ended up not meeting.

This new client is my favorite type of client. Having seen how a project can go wrong, they become far more interested in what it takes to have a project go well. They’re willing to accept that, despite its lack of visual and physical manifestation, software has size and complexity and that we need to engineer solutions that work well. They’re willing to be educated in what this takes, and willing to invest in educating us in what they want the software to do.

That education is the key. Without it, success becomes a hit or miss thing, perhaps ultimately homing in -if we’re all lucky – on a workable solution. With that education, however, we can deliver well engineered solutions which meet our clients’ needs at reasonable investments of time and money.