Paul Kimmel

Dr. Dobb's Bloggers

What Bugs Me

August 18, 2010

Most of the code we all use is part of a framework, probably as much as 90% or more. Yet some developers and some managers refuse to search out existing code with intent and prefer to build in house. The reasons for doing so are all bad, and if I might be so bold to say are almost always wrong. Think of every project as buying and assembling software as the default approach and write code only when you must.

It still bugs me that we know so many things about software development. There are canons, guidelines, best practices, rules of the road, we all have heard of death marches, yet as a community, an industry we still make the same mistakes over and over. For example, many developers still build their own data access layers. Worse, many companies refuse or resist using existing code, and I want to talk about that.

Mistakenly called 3rd party software, there are really just two kinds of code: code you write and code you don't. I call code that I don't write other party code. It should be obvious with so many developers using millions of lines of other party code, specifically, the .NET Framework (or other frameworks), that we are all using more other party code every day than code we write, yet resistance to going further is prevalent.

Everyone has heard the platitude that it is better to by then build. The resistance to building is expressed verbally in a couple of ways: we don't use third party code, developer time is already paid for so buying something is an additional expenditure, and there is the I can build it better than anything I can find. These are all fallacious arguments.

Everyone uses 3rd party or other party code -- see the second paragraph -- so this argument is specious out of the gate.

Developer time is already paid for. This argument is so bad, so wrong. Every tick of the click is a chance to add a bug, miss a deadline, make a mistake, but code that is written by another party, especially one that specializes in that part of your solution, is called leveraging your time. Suppose XYZ company specializes in controls. They may have dozens of developers, maybe hundreds, working around the clock on just controls. These developers have hundreds, maybe thousands of hours of experience. The documentation is written, after the third or fourth rev the bugs have been pounded out time and again, and more than likely there are a couple of tiers of support. There is no way that a 10, 20, or 50 man team is going to have that kind of specialization that experience. Often as a suite or sub-program you buy from specialists can be had for a few hundred bucks. Even a thousand dollars is about two days of developer's time. Two days is enough for perhaps the best developer to hack out something. Notice the intentional use of the word hack. Those two days would be better spent pounding out requirements and interacting with customers and assembling pre-existing bits then trying to learn how to write a designer for a control. The solution: if you hire just one or two developers at say $50k to $100k per year you will have enough in your budget to buy almost every piece of existing other party code on the planet.

Finally, there is the I can build it better because I am smarter than XYZ company's developers arrogance. One person may be smarter than one or even all of XYZ company's developers but they have teamwork, massive amounts of experience and a profit model based on building the best mousetrap. The one smart guy doesn't. The one guy's profit model -- unless you are competing with XYZ company -- is based on delivering a whole solution not a single control or suite of controls.

Suppose we concede that the guy next to you is the smartest guy because he believes that he can build anything and done so enough times that you believe too. Ask yourself, would the smartest guy really rebuild all tools because he can or go to the tool store and buy some really good stuff? Which approach would be faster, likely to be more reliable, and ultimately cost less?

To wrap up it is worth noting that on top of all of this there is the long term cost of intellectual property ownership costs. If you build it in house then you own it. Writing all of your own code is kind of like making babies, you own them for life.

How do you solve this dilemma if it is your pointy headed manager making the decision to build everything in house? Have a very pointed discussion where you figure out how many bodies you are going to rent and agree to rent one less and spend the difference on all the tools you can leverage for your problem domain. It is my suspicion that with really good requirements and a lot less code writing and a lot more code buying any group of developers will be substantially more successful.Most of the code we all use is part of a framework, probably as much as 90% or more. Yet some developers and some managers refuse to search out existing code with intent and prefer to build in house. The reasons for doing so are all bad, and if I might be so bold to say are almost always wrong. Think of every project as buying and assembling software as the default approach and write code only when you must.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!