« Topic Oriented | Main | django: display the name of a choice field instead of its value »

We see no silver bullet

Scott Rosenberg:

"programmers are programmers because they like to code -- given a choice between learning someone else's code and just sitting down and writing their own, they will always do the latter. And the programmer who says, it will be faster for me to write it, rather than to learn it, is usually correct. Except that what he will write, most likely, is something that will work but will not have its rough edges worked out, will not have the benefits of a piece of software that has actually been used for a few years, where the bugs have been found and the users have given feedback and have helped you figure out where the problems are. So what they will often be handing you at the end of that I-can-do-it-faster-myself thing is something that works, but that is kind of a mess in certain ways. Whereas the thing that you were going to pull off the shelf, maybe it will take the programmers a while to learn it, but once they learn it enough to hook it up to this project you are creating, what they are hooking up will probably have a lot fewer problems."

Wow. The problem here is that somebody accountable for a software project, but who doesn't know much about the activity of software development, might just believe this.

The counter-arguments are depressingly easy to state. One is integrated innovation - project failure due to issues with integrating third party dependencies and/or delays in key components. Another is "last 20% equals next 80%" syndrome - missed requirements or changes ensure the COTS option does not meet needs and the project proves to be extraordinarily difficult to bring over the line via customization, as the COTS component was never designed to be customized or meaningfully extended to begin with. In the worst case the subsystem has to be ripped out and rebuilt, derailing the schedule. Perhaps Rosenberg doesn't know, but "hooking up" software is an entire industry sector in and of itself, one of the most complex - it's called systems integration.

"We see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity." - Fred Brooks

Developing software isn't hard because of just one thing, just one dimension of activity. In the meantime, trash talk about programmers, who are some of the most intelligent and inventive people you can find, is unlikely to produce better results.


February 6, 2007 10:32 PM

Comments

Geva Perry
(February 7, 2007 04:46 AM #)

Bill --

This is an interesting discussion. I think that both you and Scott Rosenberg make good points, and I didn't take what Scott writes as dissing developers. The truth is that some developers often prefer to write code from scratch when they would be better off buying or using 3rd party open source.

In some cases, as you point out, you're better off writing from scratch and avoiding painful issues, integration among them.

Either way, both your and Scott's positions strengthen my point in my blog (link below) that there is a unique challenge in marketing software to developers, because the Build-or-Buy dilemma is more dominant than in any other industry.

This is the link: http://gevaperry.typepad.com/main/2007/02/marketing_to_de.html

James
(February 7, 2007 06:54 AM #)

Scott Rosenberg
(February 9, 2007 05:03 PM #)

I'm saddened that you found my comments to be "trash talk about developers," because I've spent the last several years of my life talking with and observing developers at work, and I have nothing but respect for them.

I'm curious why you assumed my "pulling off the shelf" meant COTS, which I understand to mean "commercial off the shelf," as most of the development work I have participated in and/or observed is in the open source universe, not the commercial realm.

"Developing software isn't hard because of just one thing" -- exactly. "Dreaming in Code" is a 400-page book that tries to get its arms around as many of those things as possible.

I appreciate your continuing this conversation -- I just don't get how my observations on reuse, a notably thorny and complex issue (according to, among many other observers, Brooks himself, whose work I thoroughly cite in the book), can be dismissed as patently not credible.

Bill de hOra
(February 9, 2007 09:06 PM #)

"I've spent the last several years of my life talking with and observing developers at work, and I have nothing but respect for them."

Perhaps the interviewer/editor failed in their job to convey that. The overriding message I got from that piece is that developers can't be trusted to make technical strategy decisions, they'll always indulge themselves. I'm sorry, but that's a terrible message. I have met people who believe this stereotype of developers to be true, but it's a myth. The piece needed to be countered with the risks inherent in attempting to re-use software.

"COTS"

Common on the shelf, not commercial off the shelf. But this is nit picking.

"I appreciate your continuing this conversation -- I just don't get how my observations on reuse, a notably thorny and complex issue (according to, among many other observers, Brooks himself, whose work I thoroughly cite in the book), can be dismissed as patently not credible"

It's presented in manner that lacks credibility, there's not much I can do about that. Perhaps the problem is with how Salon ran the story; I accept media will tend to oversimplify and present things in a one-dimensional manner. But if you think how I'm interpreting your words is wrong, please show me how - "given a choice between learning someone else's code and just sitting down and writing their own, they will always do the latter." - is a decisive statement to me.

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/2035