. . .or it can be a lie. In my last post, Evan commented that low cost only goes so far. I see where he is coming from. Let me illustrate. If a consultant puts together a system very quickly and doesn’t pay attention to the quality and structure of the system, he can deliver quickly in the short term. The client initially pays less money, and he is happy. What actually happened was that the client received a lemon. The software meets the initial requirements, but it has a handicap with intolerance to change (which is inevitable). There are probably cobwebs lurking in every corner. The same consultant will probably be asked to add features at a later time “because of the great job he did”, but the second revision will cost significantly more because he will be faced with the poor decisions made in the past. The second project is unlikely to be as inexpensive as the first, and it is very likely to be bug-riden and unstable. The initial software delivered was a pig with lipstick on it. I compare it to a bridge that works great at first but starts to crack and shake as the years go by.
The above is not providing the lowest cost to the client. It is front-loading cost savings only to defer the actual bill to a later time. Credit. Technical debt. The first release incurred technical debt the client will ultimately have to pay back.
This is not my model for consulting, and in this post, I hope to educate you on real low cost consulting.
What is real low-cost consulting, and how do we maximize ROI for the client?.
First, we want consistent clients. We want to serve the client so well that they come back for the next project. That doesn’t happen if all we deliver is technical debt. Here is the plan. First, we start the project with very high standards. No bugs. We don’t plan for bugs. We don’t allocate time in the project for bug fixes at the end. In fact, we give a warranty for the software. If there is a bug found later, it’s covered under warranty. We keep the software bug-free at all times. When a bug is found (because, yes, it happens), it becomes the highest priority. We fix bugs right away. If a requirement/use case/story is found to be flawed or lacking analysis, then that is a separate issue that’s taken up with the client to find an acceptable course of action. We are able to achieve this by building quality in. All the fundamental principles come in to play: separation of concerns, cohesion, depending on abstractions, etc. We use extensive automated testing throughout the project along with continuous integration to provide rapid feedback that everything that works continues to work. After all, after the first feature is added, that feature is in maintenance mode from then on. By concentrating on maintainability, the software serves the client well, both now and in the future.
But doesn’t that end up costing MORE?
No. On the surface, it might seem so since our standards are so much higher, but the end result is a lower cost and, consequently, a higher ROI for the client. Let’s examine how that works: First, we ensure we are building the right thing. That eliminates the waste of building the wrong thing. Next, we start testing immediately, not at the end of the project. That means that bugs are found immediately, not right before release. When bugs are found/fixed immediately, there are never more than a handful of outstanding bugs, and many days there are none. The software always works as expected. Next, the architecture is of the highest quality, and it evolves over time. With refactoring, the software is always well-suited to the problem. The code depends on abstractions and is therefore resilient to change. New types can be added to the system for new features, and working code doesn’t need to be modified (open/closed principle). There are so many interlocking practices that go into achieving this that it is hard to list them all. We keep the build fast and clean so it provides valuable feedback quickly. With quick feedback, we can course-correct to ensure we are always on the right track.
End result
The end result is a system delivered at the lowest cost possible, not just for the first release, but when the client asks us back for a follow-on release (which they do), we are able to repeat the process and deliver a 2nd, 3rd revision with the same results as the first.
But why doesn’t everyone do it that way?
It’s hard. Very hard. It hard to get the quality people that can make it happen, and it’s hard to find management that has the experience to make it happen.
I don’t claim to have all the answers (because I don’t), and we are constantly improving over time, but I can say that delivering the highest in quality also ends up costing the least.