June 2, 2008 at 10:14 am
Steve Jones - Editor (6/2/2008)
I have a reciprocating saw, though I haven't used it there. Typically I've found doing the work myself means that I can afford to mess up completely once and still save a few $$ over hiring someone.Jeff, interesting notes, and I'm curious about one thing from your perspective: testing. Inspections seem to provide some measure of quality and durability in building, regardless of following progress. What about in software?
Also, are there ways to better map progress from developers?
Steve, testing is where the analogy really breaks down. In construction, testing is pretty much limited to checking the specs on the concrete you pour (slump and hardness testing). Other than that, it's inspection. Is the lumber properly graded, are there enough nails in the plywood, etc. Do the toilets flush and the lights work?
In software, you can't do this, so you test, at all stages. As I write, I'm continually testing the code. When I'm done, I turn it over to a tester who gives a thorough wringing out before we package it up for final acceptance testing by the client(s).
The only reliable way I've found to track progress from developers is to have the project broken down into small enough deliverables that you're not caught with your pants down waiting on a developer to deliver a big chunk of the project and failing to meet the schedule. Having smaller pieces means having smaller surprises. It also means more planning, so there's a tradeoff.
The bigger the project, the more important scheduling is. This is true for both construction and software development. The trick is to apply the proper amount of process to the project so you don't mire down minor efforts in major process.
June 2, 2008 at 10:19 am
Loner (6/2/2008)
However I found out the house was built to the specification, but I found out there was always something I wanted to change. That I can relate to my customer, when I design a database, a report or a webpage, even you do everything according to their specification, they always want something different after you finish !
That's the trick, though. Were you willing to rip out a wall or at least some sheetrock in order to make the change, knowing it's not just that task, but also the re-painting, etc. that must take place afterwards? Most people realize something else they want but don't bother with the trouble. With software, changes are generally cheap enough to ask for much larger, structural changes... or at least it seems that way. I find it much harder to predict what parts of my code are "load-bearing" than when building a house.
June 2, 2008 at 1:41 pm
Wow, it seems like everyone agrees that software development is like building a house. I'll go ahead and stick my nose out and be the first to say that I hate it when people use that analogy.
To me, when building a house you are given blue prints. Chances are you didn't draw those blue prints. So they are like instructions, given to you by someone else, that tell you exactly what to do. If I were to draw an analogy of that to software development, then I should be given pseudo-code!
June 2, 2008 at 2:05 pm
I know from the residential builders that I've talked to that they rarely stick to a blueprint 100% for a lot of different reasons. I changed many aspects of the design of my house as I was building it just to keep the boss (my wife) happy!! 😉
I believe the point to Steve's analogy was that the "blueprint/design spec" serves as the initial concept, but you have to proceed with a carefully thought-out plan in order to meet the "expected final requirements". And, know how to adapt to the realization that those final requirements will probably change several times during the build process.
Trust me... Pseudo-code comes MUCH closer to "telling you exactly what to do" than any blueprint does!
June 2, 2008 at 2:36 pm
gary.clinton (6/2/2008)
I know from the residential builders that I've talked to that they rarely stick to a blueprint 100% for a lot of different reasons. I changed many aspects of the design of my house as I was building it just to keep the boss (my wife) happy!! 😉
That's a good point, but how much variance was there? Did you add a whole new room or change a window from a flat window to a bay window? Did you change what was originally a flat roof to an angled roof? Even given pseudo-code, you are bound to derivate a little as you refactor or find a potentially better performing means of achieving the same thing.
If you are sticking pretty close to the plan, you are not going to find an indoor, half-court basketball gym above the garage that wasn't in the original blueprints. Software seems to morph in such ways.
June 2, 2008 at 2:57 pm
I like the analogy.
I also like the manufacturering analogy for team development. My father was a draftsman. He drew up the plans and manufacturers followed precisely what was drawn. They created each piece, assembled it, and tested it before shipping it out.
A good piece of software is designed first, then distributed to each developer to created their own piece. When the pieces are put together it works as designed, hopefully.:hehe:
Thoughts: 😛
If software design is like building a house, does that make maintaining the application like flipping a house? (bugs included)
You can bury uniforms in foundations of stadiums and maybe Jimmy Hoffa. What's buried in your software?
In well organized shops, this analogy holds water. In less organized shops, it is more like planting pumpkins. You work the land (talk to the right people), spread lots of fertilizer (sales job), plant the seeds (start development), watch it grow, and grow, and grow (scope creep), until the vines are everywhere (spaghetti code). Finally you get this huge fruit (product complete) that somebody carves up (complaints that it doesn't work the way they asked for it).
Q
Please take a number. Now serving emergency 1,203,894
June 2, 2008 at 3:37 pm
Interesting thoughts, and I'm looking forward to seeing what you think about tomorrow's comparison.
Jeff, inspections are often third party, city or county employers, isn't that better than having the developer inspect their own work?
June 2, 2008 at 4:38 pm
I basically changed at least 50% from the original blue print when I built the house!!! I actually drew out the house plan and took it to the architect and told him that was I wanted in the house and told him to change the blue print. I should study architect instead of computer, it seems so much more interesting !!! Actually right now I like landscape architect !!!!!
June 3, 2008 at 9:21 am
I like the basketball court analogy. Sometimes in software development the finished product barely resembles the original design spec.
June 9, 2008 at 8:46 am
I still like: Software is like building cathedrals, first we build em, then we pray.
Funniest line I have seen yet.. and sometimes, so very close to the truth.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply