I walked into my client’s offices one day and almost before I had got my coat off I was greeted by one of my client’s architects and told to meet them in a room once I’d got myself composed. Luckily I’d bought my coffee on the way in. In the meeting was my current project’s manager and an enterprise-level architect and he started by saying “Ignore what you’re doing at the moment we have something far more important for you"...
They had a performance problem with one of their new services that was waiting to go into production, but the performance problem was being stubborn to diagnose and so they wanted to know if we could build a simple tactical workaround that would help them move forward with the project in the meantime. The service only needed to do a simple lookup and the data set was around 3 GB. Given that the performance problem was in the infrastructure we came up with a simple in-memory solution that used a binary search so we should easily be able to cope with the necessary 10 ms response time.
All through the meeting the time-sensitive nature for the delivery of this tactical solution was a continuous theme. Basically we had 2 weeks to get it into production, which given the speed of enterprise scale software projects felt really tight, even for something apparently “so simple”. I began to wonder if the mentioning of the short time-scale was a subtle hint to get us to try and drop (or at least reduce) some of our practices, like TDD or refactoring. After all it had taken us two weeks in our current project just to get the continuous integration pipeline up and running! Also the service implementation was far from rocket science as there was virtually no “business logic” to speak of.
Fortunately the answer was a firm “no”. My client also believed that the fastest way to deliver this project was to do it properly, just at we had already been doing on the other one. Past experience suggested that when time was of the essence people sometimes regress to old habits in a belief that they can cut some corners and save time. Tactical solutions, which we all know have a habit of living way longer than anticipated, are particularly susceptible to this kind of thinking.
After 3 days (including the day of the initial meeting) we had the core build pipeline and web API up and running so that we could demo it and, more importantly, so that the downstream team could start coding against it. And we had a decent set of unit and acceptance tests in place, written in a test-first manner. By the end of the week we were good to go as far as the web API aspect was concerned and a few days after that we had written the other tools and scripts we needed to handle the upstream data.
Sadly we didn’t quite make the deadline. But that wasn’t down to the software being late, it was all the other enterprise-y problems, such as getting the staging and production environments built, and testing integration done between the dependent services. This had a knock-on effect on the deployment scripts as infrastructure was reconfigured late in the day.
It’s great that we kept the faith and delivered a time-critical project using all the same practices we used for more lengthy projects as it showed that techniques like TDD and refactoring do not slow you down. Of course what was different this time around as opposed to the start of our main project was that the team knew each other well, we managed to leverage a lot of the knowledge and tools we had gained earlier, such as a shared library of common infrastructure code. We also had logins and permissions that we could reuse rather than have to procure new ones, at least for the development side.
Where we did slow down was in the final deployment and testing in the staging environment. But this should be no surprise because none of us had any experience with this aspect of the development process with that particular client. Consequently many of the “non-functional” requirements such as deployment, logging and performance monitoring needed heavy tweaking to fit in with their operations model. We had prepared as much as we could from experience but every enterprise is slightly different.
It feels silly now to have even doubted my client’s loyalty to our development process. They may still have many other classic enterprise traits but at least a lack of faith in agility is not one of them.
No comments:
Post a Comment