“We should send this to the client before every software development project,” one of my colleagues said to me in a Slack message. It accompanied a link to a TechCrunch column by Jon Evan about the oxymoron that is a software estimate. It outlines why software projects are almost always late, more expensive than originally thought, and hard to corral as a project. Here’s an excerpt:
Writing software is rarely a matter of doing something you already know exactly how to do. More often, it involves figuring out how to use your available tools to do something new. If you already knew exactly how long that would take, it wouldn’t be new…More typically, the thought process is more like: “I can see how I’d do it if I were rewriting that whole controller from scratch, but that would take days … is there an elegant hack where I can change the inputs to this function in such a way that I don’t have to rewrite its code? … what if I monkeypatch it at the class level? … wait, maybe there’s an API call that almost does what I want, then I can tweak the results — hang on, what if I outsource it via an asynchronous call to the external OS?”
In our experience as software creators here at Maark, there’s a lot of truth in the observation. Creating software is a complex task, both intrinsically and due to other factors such as the proliferation of platforms and devices out there and requirements that change in situ. Even something as simple as a change in a design element, something that’s relatively simple in a creative project like a brochure or a PowerPoint presentation, could have far-reaching effects on the development of an app and its timeline.
But there is a secret to software estimation. It’s the same secret that is the key to everything in work and life: communication. The client needs to know before any SOW has been signed what they’re in for, especially if those clients are new to software creation.
It’s like old-school Catholic marriage counseling, where the priest sits down the prospective couple who are aglow with the potential of their marriage together and gives them a reality check. That marriage is hard, full of risk, and not something to be entered into lightly.
Actually, that’s a more apt analogy than at first glance. Software isn’t your usual agency project, where when it’s done, it’s done. At some point you call cut on a video. At some point the campaign launches. But software is a commitment. By both parties.
On the vendor side, it’s a commitment to being up front with the client when there are potential issues. To not being overly confident in estimations and timelines. To walking clients through documentation until they definitely understand it. To make sure costs are kept reasonable. To ensure that the software works. It has to work.
On the client side, it’s a commitment to putting in the effort to understand complex information architectures, wireframes, and requirements docs. It’s a commitment to understanding the ramifications of change. It’s a commitment to constant QA. It’s a commitment to upkeeping that software throughout its life cycle.
Because software is never, ever done. Not until its completely obsolete. The changing market of operating systems and devices and browsers and other platforms ensures that, not to mention changing IT and user requirements.
If a client isn’t ready for that type of commitment, maybe they shouldn’t be creating software…that is, unless they’re willing to go through software counseling first.