Introduction
Once upon a time, in an earlier millennium, I was working on a greenfield project for a small company. We were making progress but, you will be astonished to hear, not hitting our initial estimates. In an effort to help me improve my efficiency, our MD sat me down and explained, in great detail, how every day of the project cost the company thousands. Not just through salary costs, but also social security payments, tax, hardware, rent etc…
I remember coming out of that meeting stunned and determined to redouble my efforts. For the next month I even felt guilty taking coffee breaks, and wrote some of the best / worst code of my life (depending on your point of view). The effect on my mental health did not go unnoticed. After a few months the same MD took me out to lunch, to caution against over-identifying with the project and developing a ‘Sir Galahad Complex’. Needless to say I found it hard to balance these mixed messages. It is this balancing act that I would like to discuss. When I use the word ignorant I mean it in the original sense — to be unaware and uninformed of some state of affairs. In a business context this is where an employee is not cognisant of the costs of their actions. So should Software Developers be aware of the day to day financials of the project they are working on? Folks who haven’t worked as a junior developer will immediately answer ‘yes’. How does it make sense for an employee not to be aware of the big picture? But I would argue there is only so much pressure you can load onto any one individual. Sometimes we have to acknowledge that Cypher’s point of view is correct:
I believe there are two good arguments in favour of shielding developers from the details of the project budget:
- To help them overcome Developer Fear
- To provide the freedom to experiment
Overcoming Developer Fear
As an industry we need to acknowledge that Developer Fear is a very real thing. Every coder knows the pain of reading themselves into an unfamiliar codebase, and also adapting to new languages and frameworks. Change requires growth, and growth always involves pain. This pain can be mitigated but never entirely removed. As a professional trainer I often see talented and experienced developers grinding their gears as they abandon the old orthodoxy to embrace the new one. Given the pace of change in our industry I’ve often heard CTO’s speculate as to whether there is really any distinction to be made between junior and senior developers. When platform shifts are happening every few years, and existing wisdom can be as much a hinderance as a help, is there really such a thing as a ‘senior’ developer?
I would say yes for two reasons. Firstly, because the underlying concepts never change. There has been nothing truly new in IT since the 1980’s. Secondly, and more relevant here, experienced developers become inured to the frequent platform shifts, and hence better able to manage the anxiety. As Ellen Shapiro pointed out recently, via the graph below, there is a certain accompanying level of ennui. But the resilience is there regardless.
Simply put Junior Developers have enough on their plate to be going on with. Typically they have already loaded themselves up with angst over their (perceived) sluggishness in grasping the architecture and intricacies of the codebase they are working on. To burden them further, with the crushing weight of commercial realities, will only impede their progress toward proficiency and invite burnout. As a developer becomes more senior they can increasingly be exposed to business realities. That’s a key step if you wish to transition into becoming a Product Owner, Scrum Master, Consultant or Project Manager. But it’s a bell that cannot be un-rung, and will colour all the choices you make going forward. Which leads us neatly to my second argument.
Freedom to Experiment
Agile methods, such as XP, Scrum and Kanban, have done a lot for our industry. In Ye Olden Days, teams were forbidden from working with customers and slogged away for months without any meaningful feedback. These days even junior developers are interacting directly with clients and receive rapid progress on how successful their efforts have been. This is unreservedly a good thing.
However there are no gains without losses, and the move to Agile has not been pain free. In particular teams no longer have the ‘percolation time’ they would have enjoyed during Waterfall. When iterative development first become mainstream, six week iterations were the norm and four weeks was only for the brave (or foolish). These days four weeks is seen as self-indulgent and two weeks is common. Whilst great for gathering feedback, extremely short iterations foster a mentality to ‘stick with what you know’. There is a tremendous temptation to take the safe path, via familiar frameworks, designs and tools. In fairness Agile has always had the concept of experimenting with ‘spike’ applications, but this is of little benefit when there is no time to recover from an unsuccessful experiment before the next client demo.
As with Developer Fear this is an unavoidable drawback of current software methodologies, which will be made worse by dwelling on the steady erosion of the available budget. Modern Agile teams are already under enough pressure to provide results in limited timeframes. Once again any additional incentive will be counterproductive.
Conclusions
Hopefully I’ve made the case that junior developers should be given a safe space of blissful ignorance to play in, and only slowly exposed to the cruel realities of business. This is a key reason why the Project Manager role is indispensable, to the distaste of some Agile proponents. A good manager who can run interference for their team is invaluable. If they can give their team enough slack to grow, but not enough rope to hang themselves, then the developers have the best possible chance to succeed. This is especially the case when it comes to setting realistic budgets, negotiating incremental payments and justifying overspends when they occur. It is to the benefit of everyone if the developers can be abstracted from as much of this as possible, and instead simply know they are delivering value at an acceptable cadence.
