Will the Architects win the war against poor quality software and development time cuts? First, start with Amdalh’s Law & rescue your time.
High time, software architects start convincing business on the extra efforts needed to build a beautifully working software. The comeback of the NFRs.
I am a firm believer that if the software architects took upon themselves to fight for the cause of building a piece of code that is more like a “Pizza” than a “Spaghetti”, this battle of getting more development time, will be won. It will be won all across the world.
But I agree, that battle for quality is not an easy one to win. What kind of whizkid would you be if you cannot deliver the code overnight? If you cannot make the application up and ready in half the time that you had planned for? Right?
No. That’s exactly the kind of bait that Architects must decide to not fall for anymore. It is no more about how good of a whizkid you are. It is more about the eventual cost savings for your customers. The eventual win for the business.
Yes, Architects can and must speak business now.
So what will help you rescue your time that is rightfully yours?
The laws and equations that you have always known. Applied to business.
Amdalh’s Law is one such concept. Amdalh’s Law is a very simple exposition from the world of Hardware. If you make any improvement in performance of some part of a chip, the overall performance improvement is dependent on the significance of that part in the overall system.
Common sense. Obvious. But here’s how it impacts you.
Imagine you are being told to develop a piece of software in half the time. Why? So that customer can see 2X improvement in the time of delivery. Well that is never going to happen. Never. In this universe with applicable laws of mathematics and physics, it will never happen. Here the simple math of Amdalh’s law that proves it why,
You must understand that for a customer the overall time saving is for the software development life cycle. Now if we look at your project, this is what the percentage time distribution of your SDLC is typically going to look like
Requirement Gathering — 20%
Analysis — 10%
Coding — 40%
Testing — 20%
Deployment — 10%
Let’s call the time taken for the entire SDLC with your regular coding schedule as t1
so t1 = 0.2 *t1 + 0.1*t1 + 0.4* t1 + 0.2 *t1 + 0.1 *t1
or, I can club non-development percentages, then, t1 = 0.6 * t1 + 0.4 *t1
now imagine you listen to the business and bring the down your coding time to half. That means your new time is (0.4 /2 )* t1
Now, the new time t2 = 0.6 * t1 + 0.2 * t1
That is 1/0.8 or 1.25 X improvement for the customer. Even if, using some magical means from the plane of the gods you could bring the coding time to 0, still the maximum improvement will be 1.67X. You see your customer cannot see 2X improvement just by cutting your coding time to half. Not in this universe.
You should tell it straight up to the your business, by virtue of Amdalh’s Law, you will never be able to show 2X improvement by these shorts cuts.
On the contrary, they will be making a big loss.
Yes. We are not done yet. Let’s now move to the most “unobvious” implication of Amdalh’s Law.
Consider a complete software life cycle. It includes maintenance.
In a world where time is money, it is well known that maintenance phase accounts for more time and money on software than the development phase. Around 80% on maintenance and 20% on development
Let’s assume the time taken for work on software during it’s entire life is T1
Then, T1 = 0.2 * T1 + 0.8 * T1
What if you could cut down the maintenance effort (equals time) to half? How do you do that? By virtue of NFRs. By not cutting down on development time. By building a quality software in the first place.
So, if you are able to reduce the maintenance time to half, then, lets see the kind of TCO improvement you can bring in for your customers,
the new T2 = 0.2 * T1 + 0.4* T1
This means 1.67X reduction in overall TCO. This is a huge saving compared to the small saving you are planning to make by reducing the development time to half. In development you were making a saving of 1.25X of the development cost. Note development cost. Not overall software TCO. Which is actually a very small amount saved.
So by asking for that extra development time or by sticking out your neck on not cutting down development time to half, you are actually doing a big favor to your customers.
You are saving them a huge cost. Because in the world of maintenance time is money.
Usually maintenance is a fixed amount that you bill to customers annually. This means you are actually saving money for your company. Explain this to your CEO or Business Development Head. And they will never ask you for cutting down on the development time again. Rather, they will double your development time. Because doubling the development time will have meagre impact on overall cost you incur. You will be more profitable.
But, how about something more. What if, as an Architect, you could device a scheme where you are able to cut down the time for all the stages of SDLC — requirement gathering , analysis, development and testing — to half. Without compromising on quality. Or, by delivering better quality.
I know there is no magic bullet, or magic potion or holy grail. But there are design patters, architectural patterns and frameworks that implement them. Well this is big topic for a series of articles.
In the meantime, win your battles using Amdalh’s Law.
