My long years in the tech industry have given me some perspective on how software is produced today. The developers who have just started working professionally might not be aware just how radical the change has been from the waterfall method of software development to continuous. It’s a sea change. For companies that have made the switch-over, the reduced risk in deployment, quicker development and more rapid (and accurate) feedback (in-turn, prompting better and quicker development) are huge benefits. There’s no going back.
I help companies solve their technological challenges, supporting DevOps by integrating automation in their own processes. So, partly for my own professional development and partly out of the same curiosity that got me into this business in the first place, I’m creating an app. The challenge to myself: from the moment I commit a change, the whole release process should be automated, build, test and deploy. If I can’t automate an element of code release, it doesn’t get implemented. That’s the best way for me to understand the issues my clients are facing is to deal with them, myself.
I’m creating a time tracking app for professional services. For my purposes, the app could have been for just about anything (but the truth is, I need a time tracking app. Thus far, everything I’ve seen on the market doesn’t quite do what I want it to do, tracking time across all of my projects in a seamless way and integrating with all the other tools I use). This way I get a useful piece of software as well as a valuable learning experience.
In future articles, I’ll lay out the specific challenges I faced and how I overcame them. Hopefully, this will also help add to the body of knowledge that my fellow technical colleagues rely upon to do their job. Here’s my way of giving back.
Rather than get into the technical specifics of what I’ve done so far (as I’m already well into development), first I want to delve a bit deeper into how much my thinking has changed about software development in the last while.
Shifting thinking on software development. Moving to test-driven development
I know I’m far from alone in my observations on the shift to agile development. This has been coming for a while. There were advanced, resource-heavy production offices churning out something close to an agile development process back in the late ‘90s. But the main shift didn’t really occur until the last few years. To be sure, there are still some software development companies stuck in a pre-agile process, but they are now the exception.
The old paradigm of software development is pretty straightforward: write software, test it later.
In hindsight, this was bonkers. It doesn’t really work well for any other industry, either. Imagine an engineering firm contracted to build a bridge from scratch. They plan it, build it (at a cost of millions of taxpayer dollars), run some vehicles over it… and maybe it crumbles. Hopefully not. But you won’t know until the thing is mostly built, and at great expense.
A better approach is test-driven development: you write your unit and API tests relating to each user story first. Then you write the code so that it passes all the tests. By keeping your stories small, your code batches are small and thus your groups of tests are small. That way, when a test fails, you’re not having to rework two weeks’ worth of code. It requires discipline, but it’s a much more efficient approach.
The result? You end up with close to complete test coverage right out of the gate, and when you add features, those historic tests let you know right away if you broke something. You’re not writing buggy software. You’re writing tested software all of the time that can be bundled up and automated from the get-go.
Why wasn’t I trained to do agile development right from the start?
That’s the thought that kept ringing through my head once I’d made just a bit of progress using this model. Agile development is efficient and even more rational.
But back in the day, we were taught that quality assurance and software development were two separate things.
Now, I’m also writing Unit, API, Integration and UI tests while developing the app. And since I’m also pushing the app out onto the platform it will eventually run on, I’m a software tester, release manager and ops guy all in one.
Much has been written about the divide between business and operations and the IT and developer side of companies. Agile development requires developers to be thinking much more clearly about what we are writing and how it will affect operations.
Another benefit: as I noted above, agile development also breaks up development into much more manageable chunks. You’ve got your overall vision of what the app needs to do, but we break that down into small user stories. We write the test scripts and then run the tests.
At first, everything fails, because with this new mode of development, you haven’t even written the code yet. But now you start to write the code and gradually, your red results change to green, and there is something immensely satisfying about that. Not only do you see your code working as it should but there is more confidence in it as tested code.
Throughout this process of building my time-tracking app, there were times where I was tempted to backtrack to my old habits, write a bunch of code first and then go back and create the tests. I knew that would just make things more difficult, and testing then becomes an afterthought. Before you know it, your tests start to backlog and the code/test coverage slips and then untested stuff starts leaking into the releases. Once you’ve chosen to go this route, it’s very, very difficult to come back.
For those companies that are making the switch to test driven development for the first time, or haven’t started yet, I hope you can learn from my experience. I’ll keep you posted as I develop this app, on challenges overcome and lessons learned. Thanks for reading!
