In praise of software developers who actually get the job done
A big, important project has launched — and abruptly crashed to the ground. The horrible spaghetti code is beyond debugging. There are no unit tests, and every change requires a meeting with, like, 40 people.
Oh, if only we’d had a team of 10 “rock star” developers working on this project instead! It would have been done in half the time with twice the features and five-nines availabilty.
[ Also on InfoWorld: 10 practices of highly ineffective software developers. ]
On the other hand, maybe not. A team of senior developers will often produce a complex design and no code, thanks to the reasons listed below.
Truth no. 1: You can’t afford all senior developers
Many managers have an unrealistic understanding of the labor market for software developers. Just get 10 extremely senior developers to work on an application, and presto, success! These same managers also generally believe they can hire senior developers for less than the market demands; for example, $100,000 isn’t enough for your senior-most position in most areas of the country. Best case, you’ll get one or two senior developers and eight or nine liars.
Truth no. 2: People do their best work when their head is barely above water
When you have a senior developer typewriting JSP pages (read: ASP, PHP, whatever), that person won’t actually perform as good a job as a more junior-level developer who hasn’t slogged through it 100 times before. A senior developer, even one with good intentions, will phone it in after the first few weeks because he or she is inescapably bored. A junior developer assigned to the same job will work a lot harder.
Truth no. 3: Too many senior developers spoil the code
If I were working alongside a bunch of other senior developers on a simple project like the one mentioned above, out of boredom we would come up with a way not to use JSP pages at all. Instead, we’d engineer the most powerful and flexible templating system that was not JSP ever designed.
There would be extensive discussions and architecture meetings. A pretty basic B2B website would become one of the most complex architectures ever created. Why? Because we can. We’re smart. We can keep up. We’d definitely do an entirely functional programming design because this is our chance to show our friends it can be done.
Ultimately, we’d run overtime and request “interns or something” because a few “little things” and “bug hunting” still need to be done. After a time, a handful of bright interns would end up doing most of the actual work on the project, while us senior developers exercised our whiteboard brilliance.
Sound far-fetched? I saw it happen on a multi-million-dollar corporate website project that lasted over a year. Not long before, I had led a more complex B2B portal project with a small team of four more junior people — and delivered in about three months. No one ever compared the ROI between the two projects.
Truth no. 4: Most senior developers are not senior
While conducting interviews, my company has encountered at least a dozen strong lead developers who didn’t actually know how to code. Most developers overrate themselves and align their title with their salary expectations. Knowing how to talk about monads and Hadoop doesn’t actually mean you know how and when to use them or, more importantly, when not to. It doesn’t even mean you know how to write a simple SQL statement.
Our interview process involves a coding test. It has the world’s simplest requirements: “Granny’s address book.”
Senior developers need to be able to read requirements and create reasonable code that someone can follow. They need to be able to write simple instructions on how to install and deploy the software. Most people we interview write code that throws an exception on startup and instructions that are wrong at best and poorly written and indecipherable at worst.
Truth no. 5: Arrogance goes before the fall
I’ve seen projects that were extremely sophisticated fall down in production due to very basic oversights. Generally, these were the result of smart people who wrote really “smart” code but who, like the engineers of the Titanic, thought their creation was unsinkable and neglected to try and prove otherwise.
Overconfidence is a dominant personality trait in the developer community, and it doesn’t seem to abate with experience. With senior developers, having other people tell you how smart you are can make a bad personality trait worse. We think we can handle the complexity, so we create it. Unproven technology can’t come back to bite the likes of us! We don’t need to test this one section of code thoroughly. We know it works — because we wrote it!
Talk is cheap. Results speak for themselves — and both method and materials selected by careful judgement bring results. The scientific method requires us to prove what we know. Arrogance and overconfidence cause us to believe things without proof.
Truth no. 6: Individuals aren’t the be-all and end-all
Projects are created by groups of people. Groups are organic and dynamic. Interactions inside groups are just as important as the individuals that make it up. The best groups are ones that force members to grow. Developers tend to be incredibly individualistic and always feel underappreciated.
Nonetheless, few learned everything on their own; they benefited from other developers showing them the tricks of the trade. Whether these were formal or informal mentors, they were critical in any long career. Creating a teaching environment is the most important thing a manager or lead can do. This lets you grow your own senior developers.
Senior developers need constraints. Time and budget are obvious — but to some hotshots, they’re also elastic, as complexity gets piled on complexity. When junior developers are also on the team, their ability to keep up with the high-falutin’ stuff will be limited. That’s a good thing, because it encourages simplicity, which is usually your friend.
A mixed team aligns the company’s interest with the developers’ interests. A mixed team provides a good career opportunity for all: leadership experience for senior developers and a chance for junior developers to learn new things.
