Building software is hard. Really hard. Really really really hard. Given the best possible situation, and the best possible developers, it is still quite likely that you will fail. Donald Knuth also came to this startling conclusion:
My main conclusion after spending ten years of my life working on the TEX project is that software is hard.
If you know who Donald Knuth is, then you know that if he thinks software is hard, then it is really freakin’ hard. He just happened to write a little series of books that will make your head explode. (Warning: if you don’t know what you are getting yourself into, don’t waste your money)
Okay, so we all agree that software is hard, and there are about a million things you can do to help you write better software. But I’m not here to give you the patterns of writing better software, I’m here to give you a few anti-patterns for ruining your team and your software. If you have any additional items to add to the list, let me know, and I’ll post the best ones in the future.
1) Don’t give your developers the tools they need to do their jobs. Is it really better to save 100 bucks than to have efficient developers? Seriously, your developers probably cost you at least 50 bucks an hour, so look at a tool and estimate how much time in a day that you think the tool will save you. Let’s say that we think our tool will save us 5 minutes per day, or about 25 minutes per week. Let’s say that we have 48 work weeks in a year, this will come out to 1200 minutes per year or about 20 hours! At 50 dollars per hour, we are talking about a thousand dollars. And that was just a tool that I think saves me 5 minutes per day! I know that ReSharper easily saves me 15 minutes a day, when I am heavily coding. I’ll say that I only code about 4 days out of the week (everyone deals with meetings and such). If we assume the 50 dollars an hour cost, then we are looking at about 2400 dollars per year. ReSharper is 249 dollars for a commercial copy of the C# edition and you will probably only need to buy a new copy every two years or so. We are looking at 4800 dollars over two years for a 249 dollar tool. Doesn’t sound so expensive anymore, does it? Unless your developers are going to finish their code faster and then just sit around and twiddle their thumbs, I’d say that this is a good investment. And this isn’t even considering that your tool might make your software better, in which case it could save you even more money in maintenance down the road. The only problem is that this is extremely hard to measure in any meaningful way.
2) Just jump right in, plans are for chumps. Whether your excuse is that you’re “agile”, lazy, or on a “compressed” schedule, writing software without a plan is like going on a trip without a destination. Unless you have a lot of time and resources to waste, neither is recommended. Before you start screaming at me about how great agile is, I wrote a post a little bit ago which clarifies my position. I like agile, but that doesn’t mean you can just pull great software out of thin air. Make a plan, and that plan will change, but you always need to be looking toward a goal.
3) Set strict deadlines on projects that will take “tens of thousands of man hours”. I have actually heard of people settings exact schedules on multi-year projects. You’re just guessing, and all that you are guaranteeing is constant “death marches” along with high employee turnover. If your project is over one thousand man hours, and you have an exact day that the project is going to be finished on, then you are doing it wrong. Steven McConnell wrote an excellent book called “Software Estimation” on this topic and if you are serious about estimating software the you should get yourself a copy. In his book he talks about how estimates that are given before projects start can be off by astronomical amounts depending upon the complexity of the project. As the project progresses though you can get more and more accurate ideas of how long things are going to take.
4) Spend hundreds of hours writing ridiculously detailed documentation. Seriously, the precious documentation that you so tediously compiled will be out of date in about 2 weeks. Instead, spend the time and effort making your software more usable. If people have to be hand-held through every form of your software then the problem is your software, not the users. Start thinking about inline or context sensitive help to guide your users through parts of your applications that aren’t self explanatory. I’m not saying that you shouldn’t produce documentation, but if you have to drop a 500 page manual in front of someone for them to use your software then they simply won’t use your software. Your software developers want to develop software, not manuals.
5) Refuse to buy them more than one monitor. A monitor is a software developer’s workbench. Imagine trying to do some woodworking on a 3 by 3 foot table. It would be pretty hard wouldn’t it? You have to keep swapping things out over and over to do your job. Well, developers have to do the same thing when you give them a single 17inch monitor for development. Monitors are cheap, productivity is not. Repeat after me…big monitors, multiple monitors.
6) Buy cheap hardware. I don’t think that most managers can really appreciate how much time we spend per day waiting for builds to run and unit tests to complete. They probably also don’t realize how slow Visual Studio gets when I have four instances open on a machine with 2 gigs of RAM. RAM is practically free these days, there is no excuse for your developers to not have at least 4 gigs of RAM in their boxes. Nothing is more annoying or inefficient than trying to switch between apps with a 20 second lag time. And it wouldn’t hurt to spring for a fast hard drive either. Buying a developer a faster machine is like buy a lumberjack a more powerful saw. It won’t make them better at their job, but it will make them more efficient at doing what they already do. Oddly enough I would argue that the CPU is probably the least important aspect of a developer machine, but that still isn’t a reason to get cheap! In VS2008 MSBuild is now multi-threaded, and if developers need to run big builds on their boxes it can really speed things up.
7) Keep asking them to multi-task. Every time I see this on a job listing in cringe. If there is one thing that developers do not do well it is multi-task. Multi-tasking is for operating systems. Sure, we can multi-task, but I promise you that our productivity will be destroyed by it. Developers are most of all problems solvers. Problem solving is an extremely time consuming task that requires focus and concentration. Multi-tasking is the arch nemesis of focus and concentration. Make every effort that you can to not interrupt your developers and you will have much more productive developers, and a higher quality product. I can’t tell you the number of times that I have been writing code and then get interrupted only to come back later and take 20 minutes to try and figure out exactly where I was in my project. Once a developer really gets into their groove, you don’t want to get them out.
8) Write everything yourself. You’ve probably heard it a thousand times, but the best code is the code that you don’t have to write. If you can find a tool that solves your problem, then use it. If you it costs money, then buy it. Chances are that no matter how expensive a tool is, you couldn’t write it for cheaper. If you can find a nice free tool, even better! Just make sure that whatever tool you use, get the source for it! Nothing is worse than depending on a tool only to find out that you need to tweak or extend one small thing and you can’t.
9) Expect your developers to sit quietly in front of their computer 8 hours a day. Programmers are people and we need interactions like everyone else. Most people interact heavily with others during the normal course of their work, but not all developers do. I’ve been on stretches before where I haven’t talked to other during my normal work for days on end. And when that happens I need to get away from my computer and talk with others or just take a walk. I’m not a slacker, but it is absolutely mind numbing to stare at a monitor for 8 straight hours. Sure, I do it pretty often, but it doesn’t mean that I’m going to always do it.
10) Purchase tools without consulting those who will have to use them. I can’t count the number of times that I have heard stories of companies buying tens of thousands of dollars worth of licenses for some tool that a salesman promised would save them tons of money only to find out that no one even wants to use the tools because they are horrible or incompatible. If you are buying a tool for someone else, make sure that they can and want to use the tool! Being that companies seem to want to squeeze every last penny, it is absolutely amazing sometimes how nonsensical their procurement process can be.
Now some of these items will make your software suck, and some won’t make your software suck directly, but what they will all guarantee is that world class developers will not want to work for you. Now some of this may not be your fault, you might not be a programmer and may never have thought about many of these topics. You might use one program at a time and simply didn’t understand why someone would need two monitors. But trust me, make your developers happy, and you will see your productivity (and velocity if you are a Scrum fanatic) increase!
Oh, and since most development managers probably don’t read my blog, I would recommend printing a few copies of this and then randomly dropping them around your office!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
These anti-patterns are familiar to me, I’m sad to say, although not where I currently work.
#4 (excessive documentation) can apply on the technical side too. At one job, they had a hard waterfall mindset that dictated we were supposed to write exhaustive technical documentation covering every method and parameter before writing a single line of code. It was obsolete within days of starting on even a small project, and we weren’t supposed to put time into updating the documentation since it was "done."
@David That last part about not updating documentation because it was already "done" is classic! 🙂
11) Acknowledge that developers are no different than call center employees. Give them small cubes in a huge noisy farm. Make their walls low so you can see everything they do. Make it impossible for them to gather and collaborate because there are no conference rooms, and don’t give them a place to engage in private conversations/business when needed (if they need privacy, let them make phone calls from the bathroom!)
I fully agree with this list., especially with #1 and David Weller’s #11.
I just find it appalling a company will not be able to find the money to pay $250 for resharper or the $35 for ultramon and force me to have roll back my clock to use resharper (not applicable anymore) or constantly uninstall/reinstall ultramon to continue usage of it.
My similar experience to #11 at my previous employment we went from have spacious group area multiple person blocks with each corner being a developer to tiny confined cubicles that were almost 6 feet tall so basically you could have even just went to your desk and went to sleep and none would have noticed. The few meeting rooms that had projectors that we would actually use to display code to talk about were always taken over the business people that sat around the table and talked forcing us to many times have meetings in the lunchroom. Of course by that time that place became so pointless over the course of the summer I read over 6 full novels and clocked a few days worth of naps in the bathroom
This is an awesome post Justin. The problem (as you mentioned) is to get the ones who manage developers to see the light.
I didn’t read any of the descriptions or the pre-amble, but this seems like a killer list of efficiency tips for my developers. Thanks!
Just kidding.
This is an awesome list and it made me laugh. kudos.
PS Documentation is for users and losers.
PPS I just made that up and it’s awesome.
@Ryan Yeah, all of us developers know what the problems are! 🙂
@Justin Ha ha. Oh, and nice name.
@Sara Documentation, pssssha. …rolling eyes…
As this is a post about guaranteeing your software will suck and written by a developer I’m not surprised at the perspective. As a development manager (and a developer) I see many equally problematic anti-patterns that are perpetrated from the developer side of the equation. For example, not involving customers (internal or external) in the development process is a sure way to ensure your software will suck.
A lot of the developers I know would like to work in an ideal place where they’re able to write code at their pace (and it will get done when it gets done), they have a private office, they have the latest and greatest hardware, etc, etc. (I think that developer nirvana is called Fog Creek Software…) But the reality is that they’re employed by a business that has to meet customer expectations about what will be delivered and when.
It’s only going to be when developers start working with the business stakeholders that these things will begin to reconcile themselves. Management has a long way to go before they’ll understand the issues involved in writing software, but they’re never going to get there without developers showing them the way. Likewise, developers need to do what they can to understand the business’ need.
Just caught your blog post (thanks to my annoying iGoogle homepage) and I have to say, I thought it was spectacular! I think you’ve hit on many of the best reasons software projects fail, though obviously with such high failure rates the list goes on and on. Here’s one I’ve been tossing around recently:
#12 – Do not do regular code reviews: Code reviews are an excellent way to prevent developers (especially novice developers) from significantly contributing to software entropy. It’s been my experience that the mistakes which have turned up in my code reviews are often the ones which I am least likely to recreate. With this in mind, investing early and often in this kind of open discussion within a project domain can result in considerable savings of time and headache down the road.
I think this type of review can often be ignored in the interests of ‘fixing the problem, not the blame.’ From a mentoring perspective, however, regular checkups might better follow along with the principle of ‘teaching a man [or woman] to fish’ so they won’t commit the same mistake or poor practice again.
Two interesting questions come to mind:
1. Can bad developers be made into good ones by providing the right kind of environment?
2. Can good developers do amazingly cool work in the right kind of environment?
Yes and yes, I think. But (1) comes at a high price because bad developers usually have poor standards in their DNA. But gene therapy is available and many times, the tools mentioned in this post, combined with INTENSIVE MENTORING, can cure those patients. The success rate for converting bad developers to good: probably no better than 25% to be honest. But it can be done.
Good developers often have high standards in their DNA but an upbringing that probably didn’t feed the body properly in childhood. For this class, no gene therapy is required. Good nutrition will do just fine. And the prescription includes these tools with LIGHT MENTORING. The success rate for getting good developers to be committed and do great work this way: 75%.
How can you tell a bad developer from a good one? Pick one thing from Justin’s list that you are doing wrong today. Fix it and see what happens. I would start with #7 because that’s one that almost everyone does poorly and it requires no capital expenditures. Let your developers focus on one thing at a time. If they perform better when they aren’t asked to multi-task, there may be a good developer lurking in that cubicle.
@Matt A development manager on my blog? I banish you! Just kidding, you make excellent points. Developers can be picky, whiny creatures. We often take more credit than we deserve and occasionally we think we know what is right. The interesting thing though is that what I put in my post is not difficult things to do. In fact, almost everywhere I have ever worked has only done 1 or 2 things on this list. I was merely trying to point out that there are so many ways in which teams and projects can go wrong, you need to at least start off by treating your developers as professionals. And honestly, if you think that things like buying a developer a fast machine is a waste of money then perhaps they should just write their programs on punch cards and you can feed them into a computer for them? 🙂
@Frank I agree, code reviews are absolutely top priority in creating high quality software. Even developers that have been developing for years may have built up some bad habits, or may not know a newer/quicker way of doing something. Code reviews are for everyone to learn and get better.
@Kevin Love it, you always have some nice nuggets of wisdom! And looking at the corollary of your statement, I have seen people that I think could be great developers end up hating the craft because they work at places which make them think that software development is all about implementing hack after hack and then staying late into the night debugging software which was written with no architectural rigor, while working on a schedule which was pulled out of thin air.
Justin,
I didn’t say I disagree with anything you wrote – I’ve seen a lot of these types of things. I recently took over a team that’s been having problems. What I’ve found is that the perspective of the developers and the management team above me are DRASTICALLY different. The management blames all the problems on the dev team and the dev team blames all the problems on the management. And, as someone who has to straddle the fence and see both sides I can see that both have equal culpability.
For my part, I try to give the developers the tools they need (including fast machines that don’t require punch cards!) and try to get out of their way. We’ve started to use Scrum instead of code-and-fix to bring some accuracy and predictability to the process. I’m also trying to give management what they need to launch the product, manage the sales team’s expectations and give them visibility into the dev process.
The hardest part is getting people to appreciate the others’ perspectives. And bad history makes that even more difficult. But once we’ve walked a mile in someone else’s shoes it’s easier to understand where they’re coming from.
My focuses are people, process, product and PR (to give the developers credit). We’re getting to the right place, but it takes both sides to make software development work.
@Matt That is excellent, and I completely agree that in any problem, everyone needs to accept their role in both its creation and its solution. I would be curious to hear more about your experiences in trying to adopt Scrum mid-stream and turn your team around. Let me know how it goes.
Excellent post. I think this hits on a broader problem that employees in general are often not given the trust and responsibility to do a good job. We should be fostering independent thinking and self-managed employees instead of spending so much time trying to make people color inside the lines.
I wrote a few posts about this here:
http://openbracketllc.blogspot.com/search?q=office+revolution
"You’ve probably heard it a thousand times, but the best code is the code that you don’t have to write."
Writing things yourself is a luxury. If you have the time to spend on writing it yourself, you have more of a chance understand what is going on. Also some software is still written for a specific task (as in, not to be everything to everyone). If this is the case, and you have the luxury to write everything yourself you will know how your software works, AND you can optimize for a specific task, rather than being general enough to be used elsewhere.
It is also my opinion that it is good to know as much as possible about what you work with. So to take on libraries just so you can skimp out makes you a tad ignorant.
"Refuse to buy them more than one monitor."
I have coded entire projects on an Everex Cloudbook, with a single 7" screen. If lack of dual monitors kills your productivity then you probably suck at coding. 😉
"Buy cheap hardware."
Again, entire projects, Cloudbook, $300. Sounds like someone is just being winy haha!
I actually completely disagree!
these things will frustrate developers
and you may miss your market opportunity
but really has nothing to do with your software sucking or not. Its more likely it sucks because that kind of environment is not likely to attract top talent. End of the day, software sucks if you write sucky software, if you don’t want it to suck, don’t write it in a sucky way.
@Keith You should have read until the end! That was exactly my point.
[quote]"Now some of these items will make your software suck, and some won’t make your software suck directly, but what they will all guarantee is that world class developers will not want to work for you."[/quote]
I have been reading Peopleware for last two days and I could not agree more.
Wow, that is a great post. Thanks for sharing. I am going to buy a big monitor this Christmas!
Just a slight upgrade to #2
"Don’t tell your developers the entire story."
I work on a project wherein the positive execution of my code depends on a lot of code from a lot of other developers and also, a lot of other developers simultaneously modify the same file causing a mind boggling disruption of code. The developers here need to know the entire story on how their code would affect others’ to produce effective and robust code.
This is a list that all managers who happen to manage dev teams should read.
Elroy said:
[quote]
I work on a project wherein the positive execution of my code depends on a lot of code from a lot of other developers and also, a lot of other developers simultaneously modify the same file causing a mind boggling disruption of code.
[/quote]
Elroy, I have to completely disagree. If your code depends on a lot of other code functioning correctly, and many people are modifying the same file, that’s a problem with [b]the structure of your software[/b], not anything to do with management. Look up "Loose coupling" on wikipedia.
Justin:
While I do agree that all of those things make it harder to make it great software, and are easy to fix, I wouldn’t say any of those things [b]guarantee[/b] your software will suck.
I guess "10 things that will make your developers less productive" isn’t quite as headline grabbing 😉
#0/ HIRE a professional. IGNORE his advices and warnings that chosen approach will result in lower quality product delivered late. When it happens, BLAME him.
– Well, this is probably universal thing.
@RMatl Sounds like this might have hit a little close to home 🙂