Fog Creek Software
Discussion Board

More on Software vs. Construction

Brandon Knowle brought up a great point that, IMHO, deserves its own thread: "One difference between construction and software is that a general contractor doesn't hire a cement man to do framing or drywall or roofing."

If you're an architect hired to design a bridge, they're not going to have you go out there and drive the cement mixer, or run off to change the lightbulbs on the bridge you made last year.

But many "programmer" jobs actually require you to be most of the following:

- Software Architect
- Programmer
- Database Admin
- Project Manager
- QA Tester
- Documentation writer
- Graphic artist
- UI designer
- Systems Administrator


Mike Schiraldi
Thursday, January 03, 2002

Because the roles haven't been fleshed out very well.

Once upon a time, it was common for a single aircraft designer to design 70% of the plane (everything except maybe the instruments and engines), and even participate in the building of the plane itself.  Now, you have a thousand specialists each working on only a part of the plane.  A lot of this has to do with the complexity of current aircraft, but some of it is simply a case of splitting what was once one very hard job into ten hard jobs (easier to hire for).  This pattern has been repeated many times in many industries, going all the way back to the beginning of the Steam Age. 

In software, the specialities are not firmly entrenched, yet, but I expect they will be one day.  There will always be a place for the type of programmer that does it all, just as there are still people building entire cars and airplanes solo in their garage.  It may take a few more decades for it all to take place, however.

James Montebello
Thursday, January 03, 2002

Inertia, awareness, time, predictability, pay format, and the desire to maximize revenue and minimize expenditures.

Carpenters and masons have been around for hundreds of years, which is why people who hire them have learned the benefits of knowing if you need a brickmason or a stonemason, a construction carpenter or a finish carpenter.

Programming, by contrast, hasn't been around as long; many people aren't familiar yet with the various specialties you list. Even if they are, it's all minor and "fuzzy" differences between them (they all work at a desk with computers, right?).

You may know why all those different specialties are needed, but that knowledge is not necessarily generally available outside the people who do those jobs. Do you know off-hand the difference between an optometrist and an opthalmologist, and when you would need which?

I trust you aren't presuming that it would be obvious to most people that all of those specialties you list aren't embodied in a programmer? Graphic artist and documentation writer are the only ones I'd expect the average person to consider as separate from programmers, and only because there's a large enough contingent of them and jobs advertised specifically for them. I'd expect a technically-aware manager to be able to separate out systems administrators, and perhaps database administrators as well.

To some extent, it's a matter of training and perception. In my 20+ years programming, I've only met one person who had a degree in human-computer interaction. However, in my experience, programmers are _expected_ to be architects, designers, and documentors. ("Who better than the people who implement it?")

The pay format comes in because many companies prefer to have technical staff on payroll, whereas usually construction workers are paid daily or hourly. There's a large body of extant knowledge concerning how long specific construction tasks take, and construction workers tend to be more interchangeable than knowledge workers. How many UI designers do you know who would accept "We need a design for <product>. Based on past experience, we expect it to take you <x> hours to design it, and we'll pay you $<z>."?

I work in embedded software ... a servo controller needs very little UI design. If you're developing an application targeted to many individual users, a UI designer is probably a worthwhile investment, but it is worth having one on staff? Probably not, unless you're large enough to be developing a sufficient number of products to keep him/her busy. Much simpler to have the programmers do it, because they'll end up having to implement it, anyway.

Yes, programmers tend to wear many hats, some of which we're not necessarily qualified to wear. Sometimes, it's unavoidable. More than once, I've had jobs where I have been the _entire_ software department. No UI designers, no testers, no library support, no writers, no admins, not even anybody to bounce ideas off of. You deal with it. Start your own company, and you'll be wearing every hat there is until you get some employees. At that point, they'll take a few hats from you and you'll acquire more hats.

Steve Wheeler
Thursday, January 03, 2002

One clear barrier to the division of labor in programming is the difficulty of understanding and extending the custom code written by other programmers.

Joel has made the point before that it is often easier to write code than to read it.

If you're building a house that's completely custom from the foundation up, you'll have a lot of difficulty splitting up the work. It's more likely that you'll rely on fewer workers who perform cross-discipline roles.

Non-programmer Programmer
Thursday, January 03, 2002

Frankly, I like things this way.  It lets you grow as a human.

It's just that most corporations don't know how to be learning institutions, so they believe specialization is the answer.

I think humans are capable of more than they think.  It's just that the environment must know how to incubate learning, without sacrificing the short-term.

Michael Rollins
Thursday, January 03, 2002

Mike - You’re now in the ultra-minority of people who think I have something intelligent to say. :)

James - I disagree that “the roles haven’t been fleshed out”.  Everybody knows what a DBA is, but few shops I’ve worked for hired someone exclusively for the task, even though they were needed.  Ditto for, IMO, the most important role in software: the business analyst.

Michael - The complexity possible in any software product is directly proportional to the amount of specialization within the team. The cliché “jack of all trades, master of none” comes to mind.  The Renaissance Man for the software industry died when the GUI was invented.

As for the original question “why is it this way”, I think it’s because management has no understanding about what *specific* tasks it takes to make a successful piece of software, nor defined responsibilities for who does them. 

Most shops just skip requirements and design and go straight to coding.  Then when the tester asks how something is supposed to work, the programmer does just enough requirements definition to answer the question and prays that his design can accommodate it.  Until a requirement breaks the design and all hell breaks loose.

You can never skip steps in software development.  It’s only a question of how you’re going to do them:  in a pseudo-linear, controlled fashion, or in a haphazard and chaotic manner.

Brandon Knowle
Thursday, January 03, 2002

From papers by Nicklaus Wirth, apparently technology is the main limit to complexity.  For any given performance, there is some limit to maintainability for current technology.

But I do agree that specialists can help optimize this function, and keep people from burning out. ;)  And if the renaissance person is dead, it's just because we're still in a dark age of computing.

Michael Rollins
Friday, January 04, 2002

Here in the UK Channel 4 has an interesting show about people who decided to design and build there own home.

It challanges a lot of preconceptions regarding construction.  It was an eye opener for me.

Of partiuclar interest was a self build in Brigthton

They used an alternative methodolgy created by Walter Segal.  It was a methodolgy specifically designed for building at this scale, and allowed people to move all the walls around long after the foundations were laid. 

You could call it Extreme Housebuilding, with room refactoring.

Ged Byrne
Friday, January 04, 2002

In my current job i'm a kind of software architect. However, without doing some coding once and a while I lose my understanding and feeling for the application. (i use pair programming for this).

Is this because we don't have the proper tools (yet) to analyze the software on an abstract level?

Another example: I understand the basics of EJBs, but to design an applications based on EJBs would require more knowledge of the internals to satisfy performance and stability requirements. At this moment the only way i know of acquiring this knowledge is getting my hands dirty and code.

Is it true that the lower levels of software still have a too large influence on the higher levels (architecture)?  So this would imply that the current state of software technology is not sophisticated enough to focus on an architectual level on the 'important things'. What would have to change?

Stephan Westen
Friday, January 04, 2002

What frustrates me is that where I work people are paid very good money to be Architects, and they completely fail to do their job.

Instead of detailed schematics I get child like crayon drawings, showing stick man users with big similing faces outside square houses with a nice roof and a happy sun shining down.

Then, as a poorly paid programmer, I have to fill in all the detail myself.

Friday, January 04, 2002

Shouldn't these architects get a lot of feedback on their designs?

I think one problem though, is that people with vastly different pay scales have odd troubles communicating.

Torres Jensen
Friday, January 04, 2002

I started a rant on how construction vs. software is a horrible metaphor.  Yes, it is good to have an architect make a plan before you build a house and before you write code. The details are vastly different. That is another topic.
In construction, there is money in making copies. It takes labor to make another house. There is value in that labor.  In the world of software, making copies is all but free. The programmer only adds value when they are creating new things, adding features or innovating. Doing a scratch rewrite of something you’ve written before is not worth anything.
This makes software orders of magnitude more complex to design and implement. Don’t forget programmers need to talk to each other, understand the overall design, and integrate their work. We have to know something about architecture, databases, schedules and coding.
I can imagine an architect drawing a house plan, selling it to a contractor, the contractor hires framers, plumbers, and other subcontractors, and finally the house is done. No one ever had to go back to the architect. I cannot see that ever happening on a software project.
So, can your company afford to keep a specialist on staff for the whole project? Would you rather hire a consultant who leaves when their little piece is done? To me, it is much better to have a team that is involved from beginning to end. It is cheaper and the team will produce better quality.

Doug Withau
Friday, January 04, 2002

Since this subject touches on the way teams interact to build software, I'm providing this link to an interesting article by Alistair Cockburn:

Characterizing People as Non-Linear, First-Order Components in Software Development

The gist of the article is that the success of software development projects is closely related to the dynamics of the team than to other factors, such as methodology or tools. Sounds obvious, but it's a worthwhile read.

Saturday, January 05, 2002

Doug writes:

"In construction, there is money in making copies. It takes labor to make another house. There is value in that labor. In the world of software, making copies is all but free. The programmer only adds value when they are creating new things, adding features or innovating. Doing a scratch rewrite of something you’ve written before is not worth anything.
This makes software orders of magnitude more complex to design and implement. "

I don't see why this is a reason that producing software is order of magnitude more complex. Complexity of creating software has nothing to do with making copies.

Or am i missing something here?

Stephan Westen
Monday, January 07, 2002

I like Doug's point - programming is "meta-work." You don't get paid for the product itself (since it's infinitely cheap to copy bits). You get paid for d(product)/dt - i.e. new features, bug-fixes, and customizations. In this sense, programming is less like a manufacturing/construction job and more like a professional service (e.g. lawyers and doctors...)

Dan Maas
Monday, January 07, 2002

*  Recent Topics

*  Fog Creek Home