A story is told of a product manager who got a complaint from one of their major clients. The complaint was addressed to the apparent slowness of the app when getting data from the server. As it turns out, the PM knew a code ninja from back in the day. The PM had heard that the ninja has been working on a customized SQL engine that enhanced query performance on products such as his by a magnitude and in some cases even more.
So he had the ninja brought in to demo her invention. The new library proved true and the PM promptly had the developers implement the library on a hotfix that was then released to the major clients.
Once the new app got into production, it’s weaknesses started showing, for some reason the library was updating wrong records. The PMs company got sued, he tried to pass on the suit to the developer but the developer promptly pointed to the copyleft. The company ended up losing millions in the suit and even more from a tarnished reputation.
In today’s entry we will be looking at some basic guidelines to avoid such mistakes when making design decisions.
Fighting complexity with complexity
Software projects are incredibly complex creations. It is tempting to assume that the answer to creating this complex products lies in crafting complex designs. You would be wrong.
The practise of XP explicitly admonishes this belief in their credo.
I have been surprised many times by how efficient a simple design can be. Simple designs often out perform highly complex yet theoretically optimized designs.
John Gall puts it even better.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Sometimes a monolithic app is the best answer. Your job as the developer is to deliver business value. Engineering skills are worthless if they can not generate economic value.
Simple designs require deep understanding of the problem you are trying to solve. This is hard work, but worth it.
It is at times easy to confuse the concept of simple design with no design at all.
Doing a project with no design means you accrue a ton of technical debt in the process. As we have discussed in How you pay for technical debt when the debt falls due, your project will not stand.
Lower level languages
Very few developments in the field of software engineering have been able to provide a 10* gain in productivity.
F.Brooks famously stated:
There is no single development in either technology or management technique which by itself promises even one order of magnitude of improvement within a decade in productivity, in reliability, In simplicity.
This statement was said in 1986. And it held true. But before then the said improvement was actually achieved when compilers were invented. Suddenly developers no longer had to care about machine code, only the business logic that they wrote.
From this era, the field has advanced greatly with successive languages abstracting the machine even more. Modern day languages have syntax that more closely resembles business parlance than scientific jargon.
Yet there are developers out there who want to take us back to the old days. Claims are made of the speed of lower level languages such as C or even worse assembler languages.
Unless you have a very strong case, avoid this languages and the developers who insist on using them like the plague.
Unfamiliar processes and tools
Developers are attracted to new shiny tools. That is a fact. Wether its a new IDE, language or even note taker. We love the novel.
Unfortunately all new tools have unknown kinks. It takes time for the product to mature. Obviously if you stuck to only the tools and processes that you are familiar with, you would become obsolete. With that said it is still better to err on the side of mature tools so that your team can focus on the product you are building rather than figuring out if whether the issue you are dealing with is a bug or a feature.
In my experience the above are the design problems that keep on creeping up. Tell me about your own experience on my twitter @jchex or on the comment section below.