People love talking about productivity in Software development. So much so that this conversation is probably a key contribution to low productivity.
Since Covid, we’ve been asking if remote work is as effective as in office etc. Many of the bigCos are now pushing people to go back into the office. They give all kinds of reasons but, I’m pretty sure in the back of the minds of the Leadership who is doing this they are thinking “People don’t work as much when they are hanging out at home”. I am also pretty sure that’s true for a lot of people including probably most Senior Leaders which is why they are thinking this.
At the core of all this is a fallacy where we think if we could just chain SWEs to the keyboard for longer we would then get more Productivity. A thing which we also don’t really think we can measure accurately but you know, we know it when we see it. In the end what we want is to ship software and we want it to not take so long, so it does seem like more hours typing in code might get us there.
Unfortunately, working more is rarely a good solution and it’s never a sustainable one. As someone who spent some time working in video games. I am pretty familiar with death marches and I have at times even been the person who was beating the drum. I don’t really see long hours as any kind of a solution to the problem of getting more software shipped faster. Unfortunately, the long hours are almost always a result of not being able to have any discipline defining what you wanted or what is enough. Once you burnout (or run out of cash) you decide “Ok that’s enough”.
A key thing to remember about programming productivity is that it’s not about how much code you get written, it’s about getting the right code written and, as much as is possible, only that code. If you want to deliver software sooner, or by spending less money, your best bet isn’t getting people to work on weekends, it’s making sure that the work they do Mon-Fri is worth doing.
There are several bad patterns which cause things to take too long. If you manage software developers looking out for these patterns and working to ameliorate them will give more benefits and be more sustainable than late nights and Saturdays.
Some of these are:
Analysis Paralysis – Doing some planning and design ahead of implementation can avoid a lot of problems, but it doesn’t avoid the problem of spending all your time in design and never actually getting to doing the work. Lots of software projects have used up most of their budget talking about how they are going to build a shining castle on the hill when what the customer needs is a tiny house that gets them out of the rain to start with.
Poor Specification/Understanding – Most waste comes from a lack of good specification or understanding of what is wanted. There is no easy answer to this. We’ve learned over decades that it’s almost impossible to fully specify what you need up front but we haven’t really found great ways to adjust things on the fly. The Agile movement helped, but many places it’s just devolved into just deciding every two weeks what seems important right now.
One thing you can do is try to get everyone on the team to understand the real goals of the project as deeply as possible. There’s always going to be engineers who just want to be told what to code, but you can make progress with most of them on getting better and making the right decisions as you go and spotting opportunities for improvement or simplifications along the way.
Another good technique is to always answer no to any new request. That won’t make you many friends but it will raise the bar for people making requests and avoid a lot of unnecessary work. You can always change your answer to yes once you’ve heard some good reasons, but a default no usually the best answer.
Gold Plating – Even if the system isn’t over designed it’s common to see developers trying to over engineer parts of the system. They might say they are building for expansion, or making sure there’s no tech debt we have to pay back later. Unless there’s an actual need for any of these or a real risk of a failure this generally just means things take longer than they need to. You don’t want a system that is unreliable and riddled with bugs, but just because some SWE is unhappy about tech debt doesn’t mean you have a real problem. All systems have some technical debt and you are in general better off with technical debt than financial debt.
Too Many New Toys – People like to work with the latest technology or techniques and it’s fine that a new project also tries out something new. What’s not good is to try to innovate in too many directions all at once. If you are building some kind of generic B2B Saas app, it’s very unlikely that you need to use the latest new UX stack or DB techniques. If it’s not central to your business model all of these things will force you to pay a tax, despite the glowing review you read on a blog somewhere. Popular mature platforms are more likely to meet your needs and not cause some kind of crazy diversion to happen ½ way through the project. Resume driven development is fun for a lot of SWEs but its rarely good for the team.
Having the wrong person do the job – Lots of places want to think that Software Engineers are a fungible resource. At some level of scale this might be true, but in most teams it is decidedly not. Not only do skill levels differ but developers different in which details of the job they excel at or are interested in. A good manager even if they aren’t doing all the task assignment sets up the conditions that balance the needs for the junior dev to learn new things with the teams need to deliver. You also can’t have the best developer do everything, but making sure she works on the things which leverage the team productivity well can have a big impact. As a leader in a team of developers, it’s on you to help figure out how the team can be more effective, each team has its own unique talents and challenges and it’s worth trying to untangle them.
There’s a lot more that could be said on the topic but the main point I really wanted to make is that a Good Manager is neither a person who just cracks the whip and says “Work harder” or a person who passively watches the team work and then writes the performance reviews. A Good Manager is always trying to create the conditions that the work the team is doing is worth them doing it.
Leave a Reply