Specification paradox

Have you ever heard about time dilation in physics? If not, you could google „Twin paradox Wikipedia”. Long story short – for the two twins born on the same day, if you send one into outer space, he will be older than his sibling that was left on earth. In software development it is possible to create similar paradox. I can have 90% of the app ready, but I still got 90% of work left to do. If you suggest I’ve done 50% of my work then – you’re wrong. I call it ‚specification paradox’. Let’s look a bit deeper into this.

First look on specification

I’m just a regular ‚software developer’, that people would call ‚full-stack’ these days. I don’t like that term and I have no idea why. After receiving a specification, I’m trying to estimate how much time I’ll need to deliver the app. I start with searching the most critical section of software. For now it probably means if there’s a part I’ve never done before. If so – I’m looking for the potential problems that might occur. E.g. For last few months I was making a simple Unity game. The new thing were in-app purchase. I’ve estimated that just fine, but my plan fell apart on copying user data into cloud. Nobody asked me to do that, but I’m trying to provide user-friendly software. I would be mad if I had bought something in store and wouldn’t have it on my other or new phone.

Walking on water and developing software from
a specification are easy if both are frozen
Edward V. Berard

There is also a second half of the problem – specification is almost never frozen. It will probably change and you can do nothing about it. I’m not mad on my clients – in my own projects I often see better ways of doing something and I’m not afraid to make lots of changes. As a software developer you should write maintainable code. If you don’t know how – start with „Clean Code” by Uncle Bob. But read it step by step and take notes. After that you could google „SOLID (object-oriented design)” or something similar.

90% comes from design

If it goes well – you’re done. But it never goes well. It will take another 5 years of studying, or even more, before I’ll be able to provide excellent quality. But why I’m thinking of putting 90% here, why not 50%? Imagine you’re gonna work on a new project. You read specification, know which technologies you’re going to use. Finally you create basic API, look at it and think: „Hmm, I’ve covered 90% of Use Cases, what can possibly go wrong?”.

You’re right, probably most of stuff you know about won’t go wrong. Just call this part as you wish. I don’t have a name for it, but I could put a quotation from Matrix here „Ignorance is bliss”. If it’s a designer heaven, then he other 90% stands for implementation hell.

90% comes from implementation

So, in front of you there are: your UML, basic API, specification, IDE and maybe DMBS. Then you check out that missing 10% of Use Cases and find out you can’t finish them, because you don’t have enough information from your client. If you’re an experienced person you’ll know what I’m talking about. The real problems are things we didn’t catch up while building up specification. Or they were so obvious to the client that he forgot to mention them. I’m not saying he didn’t say about key feature, but it happened to me once. And besides covering these unique scenarios, you also need to catch every exception that can happen. If I could give you the only one and final advice, what you think it would be?

How do I fight this?

Well, mockup tool can really be a lifesaver. Earlier this year, I had to face amazingly wrong estimated project. The deadline should be 300-400% longer than it was. I’ve spent two whole weeks on emailing client and trying to find out what he really needed. I knew I could do one of two options. In a good way – do software that solves client problem and at least try to meet the deadline. Or just do what was written in specification and client would never use the software, because it would be useless. I’m happy that my old Boss picked 1st option.

A lot of people would just open a document from client and deliver the app. If you use some prototyping tools you can see a lot of dead-ends that are obvious for the client, but not for you. Especially in areas you’re new to – stuff like laboratory information management system. Never take the risk if you don’t have to. It is better to spend one more week on research, rather than waste a month of work (if the development goes in wrong way, of course).