In a reflective mood today, I recalled a time when the "make it work, make it right, then make it fast" approach failed to work for me.
As part of a large-ish development team (about 20 developers, designers and testers,) I was tasked with building the data access component. It was a large, new application that was highly complex and also high profile.
I was the first developer on the team and did some early experiments and research into the new platform we'd be building for and the new framework we were to use.
After a few weeks of R&D, I went on holiday (vacation.)
While I was away (and without my knowledge), work on the project started "properly". One of my POC/experiments was assumed to be good enough to start the work, and people were quickly added to the team. While all this was happening, the app's requirements were still being decided.
When I came back, I found people busy trying to implement the individual sections of the app they had been assigned and I was asked to work on the "common data layer" that would provide everyone access to the data they needed.
I was scrambling to provide the other developers with the data they needed while the other developers were also dealing with designs that kept changing and so needing new/different data.
I just about kept up, but as the requirements of the data retrieval and caching were still being decided and worked out, I focused on building a data access API that the other developers could use and could hide the caching such that no other parts of the code had to pay them much mind beyond being able to specify if and when cached data was or wasn't acceptable. (i.e. If the user has specifically forced/requested a reload of data, then don't rely on the cache.)
I repeatedly told people, "This is how you get the data. I know it's slow, but it will get faster. I'll add the caching once things get a bit more stable."
I either didn't say this loud enough, or people didn't want to hear it.
One day, the project manager decided that I wasn't doing a good enough job with the data retrieval as it was too slow, so someone else was assigned to it. I was to work on something less important. The other person had already started making the changes and my opinion or thoughts on the decision were irrelevant. A decision had been made.
Very quickly, the other developer got the caching working. Things were stable by then, and the code was clearly laid out with comments and TODOs indicating what caching had to go where and how to implement it. I'd been leaving comments and notes for myself, so I knew what still needed to be done.
When the other developer showed what they'd done, they were praised as the savior of the data access code as they had done something I hadn't (and so it was assumed I couldn't.) My competence was also questioned: why hadn't I done something the other developer could do in a seemingly quick and easy fashion?
I had assumed that getting it right and then making it fast was the way to go.
The powers that be wanted something faster, sooner.
They were also used to things having to be changed and reworked repeatedly until they were right. The idea that anyone could get the design right the first time was anathema to them.
What went wrong:
- We weren't clear about goals and expectations.
- Communication was incomplete.
- We were working off different assumptions about what was required and what was good enough at the current stage of development.
What I'd do differently today:
- Firstly, I'd try and avoid the situation where lots of people start working on a codebase where everyone is doing different things as we all try and learn a new platform, and while the requirements were still being established.
- Be clearer about requirements and deliverables.
- Be more transparent about my progress and expected deadlines.
- Possibly, try and show something that mimics the complete final experience as early as possible. ('This part of the code shows what the final user experience will be like, but as these other parts are still in development, we haven't flipped the switch on ')
- If there's more work than can be done in the time, establish prioritisation. ('I'm deliberately not focusing on the performance yet so I can ensure everyone has the data they need and isn't blocked. Once that's done, I'll add the caching. I know how to do it, and it won't take long, but I don't want to hold other people up. Is this Ok?')
The above all happened over a decade ago but still has relevance. ;)
