A few issues ago, I started talking about a project that my team was working on with a client. It's been nearly seven months since this project's initiation and a ton of progress has been made. The major change was in the size of the development team.
Part 1: Act 1: Into the Great Unknown
Part 3: Act 3: Merrily We Roll Along
Part 4: Act 4: The Tenets of UAT
When we started this project, the team was rather small: six developers and a project manager. The purpose of this small development team was to figure out the “how” aspect of the project. How the heck were we going to consume this elephant-sized project and scale up the team? After a few months of work, we made the jump and grew our team by around 10 developers. We did a formal three-day training session and after that, we went to work. In the last 60 days, we've extended the team even further and now our development team is approximately 30 people.
It's been a learning process, and this is where I “knock on wood:” This project is going well, beyond all my expectations. We've managed to complete the first major milestone of the project and are proceeding to move parts of the project into UAT (User Acceptance Testing). Throughout, we've learned a number of lessons. Here are some of them.
Playing to People's Strengths
In his book “The Mythical Man Month,” Fred Brooks discusses the concept of organizing development teams like surgical teams. The surgeon performs the critical work while the remainder of the team supports the surgeon. Our team flipped this around. We chose small groups of developers to work on critical services of the system. These critical functions included things like frameworks, build management, help systems, paperless automation systems, user interface design, etc.
The developers of these features were considered support developers. Their job was two-fold: Build critical features while supporting other developers in their understanding and usage of these systems. Initially, these system-critical features were given to the more senior developers. As the development process progressed, we distributed the responsibility for these features to more developers as their depth of knowledge increased, which leads to my next concept, enabling developers.
Enabling Developers
One of the main goals of this project was to do a better job of enabling our developers. Every - and I mean EVERY - developer has good ideas that can help make the team more productive. We've tried to give developers the ability to try things and then to propagate those new things to the other developers when they make sense.
One of my favorite stories is how we managed the distribution of our stored procedure script files. Yes, this system is built on SQL Server and uses an extensive number of stored procedures. As a matter of fact, we have 1,000+ stored procedures that have been converted so far. When we started this project, we just ran all the scripts each time we updated our code from our master branch. This worked great when there were around 100 scripts. It only took a few seconds. It was when we added ten more developers that the flaws in this process became evident. It was taking too long to run this ever-growing number of script files. We had to do something.
Enabling developers was the answer. They created bash scripts to store the script names and dates most recently run in a local database table, and power shell scripts were attempted. Ultimately, a new script runner utility was created that took the best ideas from each developer and consolidated them into a single process. It came down to detecting changes in scripts by calculating a hash value against a stored hash value. If there were differences, the script was run and the stored hash updated. This process turned a long-running operation into a very quick run through 1000 files. This was ALL a result of enabling developers.
If there's one thing you can do to improve your development process, it's enabling developers. Enabled developers are happy developers. Each developer's ideas need to be considered carefully and, where they make sense, distributed to your team.
Don't Be a Blocker
At my core, I'm a programmer. I love writing code and after 20+ plus years, I still raise my fist in triumph when stuff works. Come on now, you know you do that too!
The sheer size of this project has greatly reduced the amount of time I could spend coding. As the project grew, I found myself getting increasingly frustrated as the features I was assigned to work on seemed to make little or no progress. This was because I was spending most of my day helping other developers and spending only an hour or two on my features. I was becoming a “blocker.”
I eventually concluded that my job on this project was to help the other developers accomplish their tasks. As soon as possible, I transferred the features I was responsible for to other developers. Almost immediately, I felt better about what I was accomplishing each day. I was able to help other developers accomplish their goals. This gave me great satisfaction, as ultimately, what we do as software developers is help other people, be it users or other developers. Did I stop writing code? Nope! I still write code. I now focus my time coding features, tasks, or tooling that help the team accomplish their goals.
What's Next
This project is moving into a new phase. The UAT phase. This is where our code faces real users. I'll be back in a few months to let you know how that goes!
