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.