When you’re starting a software project, you have to make some technology choices. You have to pick a technology stack, but you also have to pick the tools that your team will use to manage code, track issues, write specs, and collaborate over long distances, among other things.
Some of these things are more important than others, but they all matter. If the majority of the team is using PowerBooks but the UI specs are all done in Visio, that’s going to be annoying. If you’re working on something involving trade secrets (or national security), using AIM is probably a bad choice. But whether you do page wireframe drawings in PowerPoint or OmniGraffle on those PowerBooks, or whether you use IRC or Jabber over a secure connection for collaboration, is less important.
Ideally you’d be able to point to a tool that’s obviously the gold standard, and do some quick back-of-the-napkin estimates of the cost of buying everybody a license to it. Then you could compare that to how much money would be saved in terms of developer labor costs, or delays to the project end date.
But unfortunately, it’s often hard to know for sure which tool is best. The market for software development tools is crowded, as is the market for software development technologies. There are an awful lot of programming languages, and frameworks for each language, and databases (relational or other), and web servers and operating systems, and variants of each operating system. It takes a lot of time to do an evaluation of one major product, and a year later, the competitive landscape has changed because new things appear and old things improve.
(This also implies that the technology choice you make today may seem like a mistake in a year. Get used to it. It’s the same buyer’s remorse that happens when you buy a PC and then look three months later at the price of what you bought, and what you could have had for what you paid. At some point you have to jump in and buy something, or in the case of software, build something.)
The idea that you can just hire someone who knows all of the details about all of the options at every level is just wishful thinking. The complexity of each product combined with the number of products means that no one can have firsthand experience with all of it. Paid research organizations tend to make shallow comparisons based on corporate strategy, and extrapolate trends based on the fad that their subscribers want to buy more information about. Their research reports tend to be useful only for supporting a decision you’ve already made and need to sell to upper management, not for learning something you didn’t know already.
So we’re left with knowledge sharing between software architects as the way to stay up to date. And share we do – software developers are very good at sharing knowledge. Sometimes, we’re too good, and share things that we don’t actually know, such as the aforementioned gold standard. In Unskilled and Unaware Of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments, we see studies that suggest something that was pretty obvious already: the louder the voice championing absolute authority and certainty in a point of view, the more likely that person is a bozo, who hasn’t critically examined their choice vs. the alternatives. And so we get so-called “religious wars”, between the two or three contenders for the title of gold standard.
But although those are the loudest arguments, they aren’t necessarily the most important. It’s likely that among the two or three best choices, none of them will kill your project. The difference between (for example) Java 1.5 vs. PHP 5 vs. Python for a medium sized web application, with all other parts of the tech stack kept constant, probably will not mean the success or failure of your project, nor the life or death of the company. Sure, there are differences, and reasons why for one project or another you’d lean toward one or the other. But there’s a point of diminishing returns, where the argument costs you more than the gains of using your favorite technology instead of what the other folks want to use.
Now, there are some philosophical issues that matter, such as RAD vs. Big Design, vendor lock-in, product maturity, and available labor for a given technology set. These are typically not what techies argue about, because they’re business issues, not technical issues. Typically the techie wars revolve around things like performance, and bleeding edge features that supposedly make your code beautiful and make coders 10x more productive. If premature optimization is the root of all evil, as Sir Tony Hoare said, then how smart is it to choose a language based only on how fast the code it generates is? And programmer productivity is important, but this has to be weighed against other things, such as whether the runtime blows up under load, whether it can talk to your database, etc. Little details like (I kid you not) a single-threaded database driver, or no database driver at all being available for the language and database you’re using, can really screw up a project, even if that language was really helpful in getting code written quickly. And as Joel rightly notes, this is usually best settled by “what do we already know how to use effectively?”.
But if the small differences between the best of the best don’t make that much difference (and a real evaluation would take prohibitively long), there are still things that can totally kill a project, and developers for some reason tend to choose these battles poorly. I have seen many, many cases where a really awful tool was chosen for very bad reasons: a totally separate team using a different product from the same vendor, or because somebody knew how to use it and knew that it was awful but assumed that all the other prouducts were equally awful, “the devil you know” etc.
The price here is that while developers are fighting tooth and nail over two excellent options in one place, they get stuck with something awful somewhere else, and management is so sick of the infighting (or desensitized to it) that they just make a decision and the team is stuck with it. It’s no mistake that the things that developers consider to be most central to their expertise, usually a programming language, are the things that they argue about most, while peripheral things get almost no attention, and are therefore often chosen very poorly.
I’ll give you one example of a technology that can kill projects: Microsoft Visual SourceSafe. The idea with version control software is that you put your precious code in a repository that keeps it safe against accidental deletion or overwriting by other members of the team. This is a serious risk that many tools exist to mitigate. So what happens if the tool is so bad that it makes the risk worse? Don’t take it from me:
- Visual SourceSafe: Microsoft’s Source Destruction System
- Visual SourceSafe Version Control: Unsafe at any Speed?
- Source Control: Anything But SourceSafe
And yet there are reasons why some people might still choose it. It’s integrated into some IDEs. It’s been around for a while and it’s supported by a huge company. Some developers have used it before and understand its foibles.
There are other tools that are similarly problematic, at different levels of badness. Some are so bad that they simply must not be used on a project. Some are a drag and waste a whole lot of developers’ time, because something sticks and has to be manually unstuck all the time, or because it crashes and you have to write all sorts of extra code to work around the fact that it just crashes sometimes, or because it only runs on Windows NT 4 or Classic MacOS or Solaris or whatever and you have to keep a dedicated VM or physical server running in order to host it. Some are annoying but can be put up with, and don’t make more than a few % difference in developer efficiency, but those % are in your face so you feel like they’re a big problem.
The key is to know which is which, and to choose your battles. Save your breath for the fight over that tool that costs $100,000 per server and dictates the whole technology stack and promises to make the whole software project a “point and click” or “drag and drop” exercise for managers, or the tool that’s the new fad and nobody has used but everybody has heard about so let’s just decide to use it now without trying it out first, or that framework that takes over your whole application so that if you decide you don’t like it later, you have to start over from scratch. Choose your battles and fight hardest in the ones that will make or break your project.
P.S. It’s also worthwhile to have a list of “red flag” products or technologies in mind when you’re interviewing for positions in existing projects. There probably aren’t many, but there are definitely a few technologies or products that either doom the project to failure (or agonizing struggles), or indicate that nobody on the team has a lick of sense and you’re just seeing the tip of the iceberg. Don’t be afraid to walk away when you can tell that the folks on the other side of the table have made a critical architectural or tool selection mistake. You don’t need that kind of pain.