I’ve been asked more than once about software development myths, and I’ve run into plenty over the years. Here is a (non-exhaustive) list of some of the myths I’ve seen people believe. I’ve tried to focus on enduring myths, rather than short-term fads (like “Blockchain is a broadly applicable technology”).
Myths Management Believes
1. Every manager has read ‘The Mythical Man-Month’ and thinks they understand that adding more developers to an already-late project tends to make it later. However, they will still do it, apparently believing that some combination of proper management, having good people, and the specifics of a project mean it doesn’t apply in their situation.
2. Management also has a tendency to believe that large, complex software systems get ‘finished’ and then become a cash-cow, bringing in an ever-increasing revenue stream for fixed costs. Even if they do account for increasing support and maintenance costs, they rarely consider that continuing innovation and development is required to keep a product competitive.
3. Managers sometimes believes that the primary role of a developer is to translate specification into code. They don’t understand the numerous design decisions involved, the trade-offs being made, the non-functional requirements being considered. I have never once in my career encountered a specification which considered the sort of logging detail required to diagnose the types of system failures which might occur – and yet that is a key component of writing good code. Every developer runs into minor details from day to day which require assumptions or decisions to be made – and a good developer should be tracking those, communicating them, and ensuring the right people are involved in the right decisions, while being shielded from the bulk of less-important ones.
4. I have frequently run into managers who believe that their developers are not politically savvy, or that they all have poor networking skills. This can lead them to interact with other parts of the organisation in a way which under-estimates the contribution of the development team (see 3). When managers do this, their team does find out about it, and it creates resentment.
5. Managers sometimes think that developers within their team are roughly fungible. Managers usually understand that different developers have different areas of expertise and levels of experience, but they often underestimate the impact. They don’t realise that it can have not a 2x effect, but a 5x or greater effect – and that effect is not limited to time, but also to quality (but see myth #2 under “Myths Developers Believe”, below).
6. “All platforms, languages, and third-party systems are roughly equivalent” or “This specific platform, language, or third-party system will fix all of our problems”. I have run into both over the years. The former leads to upper management thinking the selection of a third-party provider such as a cloud host or database platform is purely a business decision and will have no technical impact. The latter can result in management embarking on costly technical projects to no benefit (“we have to re-write our entire codebase into [language]” or “we need to move all of our data into MongoDB”).
Myths Developers Believe
1. Developers often believe that management doesn’t have anything to contribute, or that they’re useless or unskilled. Notwithstanding the above myths, managers can make significant contributions and many of them do really know what they’re doing. The good ones shield developers from distraction, ensure they have proper equipment and software, manage outwards to get realistic (and, importantly, low-stress) deadlines, communicate early and mitigate the effects of missed deadlines, justify budgets and pay increases, bring in appropriate consultants to address short-term skill gaps, ensure meetings minimise disruption, and do countless other things to make projects run more smoothly.
2. Developers often believe in 10x or ‘Rockstar’ developers. Some developers can be significantly more productive than others, but this is usually just a matter of experience and knowledge. It is also often specific to particular topics. For example, I used to do all of my team’s low-level network programming – many on the team considered it an impenetrable field and thought they weren’t capable of doing it. A while ago, though, I took one of our juniors aside and spent some time teaching him what was involved. He is now nearly as productive as me in that area, as long as he doesn’t go too long without working in it. Once he’s relearned the skills a few times, they’ll become a permanent part of his skillset. He’ll then be a 10x programmer – but only when working on low-level networking code, and only when compared to a developer who hasn’t spent much time on that specialty.
3. “Most developers are much better than me.” Known as Imposter Syndrome, developers are particularly prone to it, due to developer myth 2. It is especially common in generalist-type roles, where a developer may go long stretches without working on the sorts of things he or she is particularly good at. Instead of treating these times as opportunities to develop new specialties, they can instead look back at periods of much-increased creativity and think that they’re a bad developer who spends most of their time being unproductive. In reality, they are normally-productive for much of their time, and super-productive when the thing which needs doing is an excellent match for their experience and knowledge.
4. I don’t quite know how this one crops up, but many developers think having a high reliance on tools is bad. I have encountered developers who refuse to use automated deployment systems (“I want to understand what’s going on, and I can’t do that if it’s automated”), refactoring tools (“it’s safer to make each change manually”), and even syntax-highlighting and code completion (“I know my language and my libraries. What if one day I’m stuck using vi on a green-screen linux box from the 70s? Where will I be then if I’m used to these fancy tools?”). I call this concrete-pill syndrome, and I suspect it has something to do with wanting to look capable of handling everything yourself. In reality, these tools (and many others) are great levers, allowing developers to increase productivity and quality.
5. “As a developer, it doesn’t matter if I have poor people-skills, because in developer roles I can ignore office politics anyway.” This is a recurring one, and it doesn’t just hurt your long-term career – it hurts your current project, it affects the sorts of projects you get to work on, and it hurts your team. I try to shield my team from the need to play politics, but I also try to let them see just how much of it I have to do. Not playing office politics well enough can leave you stuck with a bad manager (see some of the earlier myths about the contribution a good manager can make), or it can leave you stuck with a really bad external technical decision. It can leave you stuck with a really bad hire.
Earlier in my career, someone from upper management asked me: “Of the candidates for the developer role you rejected, who was the least bad?” I made the mistake of telling him, and I got stuck with that bad candidate on my team right through his probation period. I should have known to respond with “They were all unsuitable, let’s line up some more interviews”.
6. Developers early in their career sometimes think they are much better than experienced developers. I’ve heard it called ‘God’s Gift to Coding’ syndrome. It happens because they believe they are better with new technology, and new technology is more productive, and so they are worth more than someone who is too out-dated in their thinking or is stuck on old platforms and techniques. While some older developers do remain focused on older systems, they have still built up a depth and breadth of experience which is valuable. However, many developers continue to be intrigued by new technology as they get older, and keep their skills as (or more) current than many juniors.
7. This is a two’fer: “Domain experts outside software aren’t really that smart” and “domain experts have magical knowledge of an esoteric field I can never begin to understand”. The reality is that the domain experts you work with – whether they are accountants, scientists, engineers, or sales people – have years of learning, training, and industry experience which is highly valuable to your team. As a developer, you need to respect that – but you also need to be a sponge, learning what you can about the domain. If you don’t understand what you’re building, you will fail to consider important things. If you don’t rely on your experts for their professional knowledge, though, your project will be built by amateurs who happen to be good at software.
(I originally published this list on Quora but wanted to get it on my own blog as well.)