Start with a clean slate with simple goals
Starting from scratch is such a rarely privilege in professional programming. We get to do it all the time when we’re learning and trying things out. In our early years getting stuck and stumbled on the most trivial challenges. And later being proud of the frameworks and architectures we can build in days (sometimes hours).
But there is rarely any money to be made in building something from scratch. There is no value in doing something trivial because it likely has already been done a thousand times before. So we need to add something to existing code. Maybe it’s something we already developed ourselves or something we bought. If we’re lucky the existing code is modular enough that the new feature can feel like starting with a clean slate and give us that burst of speed.
So you will often hear the cries from programmers that are working with that monolithic and aging code; “please, please let us rewrite this code from scratch”. I’ve made this cry a few times in my career. Sworn to make it fast enough to reduce the cost. Promising to fix all those bugs that we now endure. Brazen enough to believe there will be no new bugs introduced this time that cannot be plucked out. We lie so much. We lie to ourselves and to the company. We lie because the pain of that old code is so real and so present.
The reality is that recreating something from scratch often takes just as long as the original did. Which may be years. Is in a race to catch the original is still being patched and enhanced in use. And the switch is still horribly painful as you have spent so long writing code before it’s put into real use and only then you find a bunch more issues. So you blow the budget, often reintroduce many of the same bugs as before, sometimes a few new ones and now hate the new code so much you cry “please, please let us rewrite this code from scratch!”
So if we’re lucky we get to work on something simple from scratch. No wonder people work for startups for stock options as payment. Or if there is an existing modular system it can feel like working from scratch. So we see such frameworks are massively popular in your language of choice. But that speed may not last.
Start with high quality code with simple goals
A system that is highly modular can feel like working from scratch. It can do this by actually splitting any operation into a collection of lots of smaller applications. The unix operating system is built on this principle. No single program does much at all. But they all implement the same basic method of handling input and output. That allows us to pipe data into and out of any combination of these programs to perform increasingly more complex tasks. There is no motivation to write a new text sort program because one already exists. There is no motivation to write a new text sort function because it is so easy to call the existing program.
But additionally the code can be very well understood and structured in a way that it is easy to change or extend. When an existing code base creates a high confidence on the outcome of any change the programmers are free to change it in any way they wish. So that existing code becomes a nice launch pad to very quickly create a new variation or addition. It may not feel like working from scratch because you may be changing code rather than writing new files. But it allows small changes to be quickly released, tested and reviewed. So progress kicks off at a blistering speed.
But each change may bring with it some technical debt. Create a new link between two modules that were previously unaware of each other and you have quickly created a nice new feature. But you’ve also created a dependency that is not obvious. Now all the tests need to be aware that one affects the other. Any new changes to either module needs to be intimately aware of this relationship that got hacked in. Further features and changes create a complex web of relationships. It starts to lose that feeling of simplicity and confidence. Then the bugs creep in. The bugs you’re afraid to fix because it might break something else way over there.
Pile up technical debt (aka make a mess)
But the customer hasn’t noticed that bug yet. They just want features. It’s the new features that make money. It’s the new functionality that will fight off the competition. As long as the system holds up and functions right now there’s no time free to fight the bugs. Nevermind clean up the code and make it more modular. We want to go fast right?
I like the analogy of the application being like a restaurant. You can present a very nice front area with great service and a wonderful menu to the customers and make a lot of money. Little do they know the mess being made in the kitchen as the chefs franticly create meals. If the customers saw the mess, the pests and the rotting smell back in the kitchen they would never eat here. None them have gotten sick… yet.
You quickly get lots of features out and the customers love the product. Sure there’s a few bugs but they’ll endure it for all the value the application is giving them. But the demand for features doesn’t slow down. Each new feature is harder to do and risks introducing bugs as fragile code is pushed beyond its original function. Outside of the programming team there are murmurings. What happened to this fast pace the programmers used to manage? How did a good team become so bad?
Keep it clean and lean
So what’s left? It’s not financially beneficial to start from scratch. Even if we start from a base of quality it’s easy to lose our way and lose that base. What allows us to go fast and stay fast? Is technical debt as inevitable as entropy. Would the second law of programming read: The sum of technical debt in software increases as the code is changed and added to?
Robert C. Martin says, “The only way to go fast is to go well”. While there are plenty of other opportunities to write code fast many of them do not last. The lasting methods embrace the key practices of eXtreme Programming (XP). Pair programming, Test-Driven Development, Design Improvement, Continuous Integration and Collective Code Ownership. These are technical practices and may not mean much to customers or project managers. There are many people in a successful business that won’t be looking at the code quality. So the responsibility lies with the programmers as only they are reading and writing code each day.
Pair programming is easy to roll out but often resisted. Many programmers learned the complex world of computing as the complex world of social interaction seemed too daunting. But code reviews afterwards are a weak substitute. By then it’s far too easy to say the design is locked in now and too hard to fix. Code reviewers understanding of the solution in place is limited while pairs discover the solutions together and weigh up the options each can bring before progressing. There are many studies with good methodologies that show pair programming can dramatically reduce the number of bugs in the final product. If you care about quality the question should be; why are you not doing pair programming already? And now many are taking it even future with mob programming getting a whole team mind share.
Test-Driven Development (TDD) drives you towards a testable solution. Highly tested code is code that brings high confidence in making changes. High confidence in making changes means even late changes are easy and welcome. High confidence in making changes gives you that launch pad to make changes quickly and get results quickly. But you only get that launch pad if you were doing TDD all along. An ideal time to have started writing these tests was ten years ago. But you can settle with starting today. In the long run TDD will make you faster for a very small cost in time (10-20% according to studies). I would argue the cost is even less for complex tasks as it gets you writing code while you’re still figuring out the full solution. And now you can add to it in so many other ways with acceptance testing, behaviour driven development and more.
Design Improvement is a recognition that the system you’re building now many not be the same system you’re building in three months. The requirements will change and evolve and so too should the design. With the high knowledge of code we have thanks to pair programming and the high confidence in making changes thanks to TDD we are free to make changes that improve the overall design after the implementation. You can change the entire architecture of your code base piece by piece to eventually end up somewhere closer to the product you have now and not the one you intended six months ago.
Continuous Integration is to help recognise problems early and fix them early. If someone introduces a bug there is a big red flashing marker to stop work until it’s fixed. Much like you would expect on a factory production line when an issue introduced is noticed. The line is stopped and the problem is resolved immediately. And why stop there? You can get continuous releases going for rapid feedback from all your customers.
And finally Collective Code Ownership is critical to keeping any team of developers working fast. If your database expert is sick for a month you cannot afford to have all production slow down. If a reports system was developed by someone who since left the company how do you explain to the customer why further additions are coming so slowly? Pair programming goes a long way to resolving this but so does the TDD and design improvements. Keeping the system simple and one that the whole team intimately understands. If a developer sees a line of code they want to fix they should feel confident in fixing it, on the spot, without consulting anyone beyond the pair they are working with.
Too often Agile is rolled out without these core XP practices and while teams are releasing in regular cycles release speed is slow. Many just accept the slow buggy releases as inevitable in software development much like they did with the waterfall code of the 90s. So great is the possibilities of going fast and there is so little to lose. Asking people to put higher quality into the code and their development team should not be considered a cost. And thanks to that quality you can write code faster.
References:
The Costs and Benefits of Pair Programming. A Cockburn & L Williams.
On the Effectiveness of Unit Test Automation at Microsoft. L Williams , G Kudrjavets & N Nagappan.
Implications of Test-Driven Development A Pilot Study. R Kaufmann & D Janzen.
http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1038&context=csse_fac
Comments
Post a Comment