May 31, 2008 at 12:49 pm
Comments posted to this topic are about the item The Software Comparison
June 2, 2008 at 2:09 am
I would suggest it's a primary objective of any DBA to ensure software development is never analogous to construction of a sewer network, although given the quality, quantity and type of data some parts of my company want to store, it's certainly a struggle sometimes.....
:Whistling:
Semper in excretia, suus solum profundum variat
June 2, 2008 at 5:11 am
A good analogy for software development can sometimes be legal contract drafting - a contract looks a lot like source code (and often should be more like it).
Before starting, the parties need to agree what the contract is for (analysis) and it's a good idea to write this down in a non-contentious way, before thinking about how to actually write the contract (requirements definition).
Both the writer and the eventual signatories need to think hard about how the contract will be used (use cases). Happy day scenarios are easy to define, but often the value is in the unhappy scenarios and any remedies (SLAs). Any logic and formulae should be defined, and this is worth doing outside of the main text, in a format where the intent and content are more important than the syntax (pseudo code).
Once there's agreement on what we're all aiming at (requirements sign-off), the jurisdiction which will be used should be agreed, especially where the parties are in different domains (agree the high level architecture and design).
Only we can start drafting (build). Both parties should read the draft and decide whether it works for them in as many scenarios as can be imagined (test).
Changes, either to the draft's detailed wording or the broad thrust of the contract, should be subject to negotiation, and we need to keep a trail of how we get to the final wording (change and version control). If we have got the structure agreed up front, it's more likely that we can accomodate detail change without massive revision (have a flexible design and agree it before starting to build).
Once the all parties are happy, they should sign to that effect, and the contract comes into force on the specified date (implementation). Should things go wrong, or needs change, all should come together to discuss any revisions that may be needed (support).
And finally "Whereas" seems to mean roughly the same as "#include stdio.h" (never meant much to me but they all seem to put it in).
Bill.
June 2, 2008 at 6:32 am
The building analogy works well. It is particularly effective if someone has been involved in a building project; perhaps less so if they haven't.
One of my professors gave this example: He had the good fortune of being able to have an addition built on his house. At one point he went in to inspect it and noticed that the contractor had provided far fewer electrical outlets than had been agreed. By this time the drywall had been put in place, so providing the agree upon functionality involved either using electrical conduit (ugly) or ripping out and the patching drywall. The latter was the result, at significant loss to the contractor.
This is a great illustration because a) it's a good example of how a seeminly small detail can cause a lot of problems and b) it puts a money concept to the problem; patching after the fact can be expensive. This is something that managers need if they're going to approve time for "insignificant" things like planning...
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
June 2, 2008 at 7:27 am
My favorite laugh at the usual "database as the foundation" analogy is that you really can't build two houses on the same foundation.
On the other hand, the usual house is a pretty good parallel for so-called code-portability.
I also have to admit that I have yet to find a software interface that has anything like the simplicity and ease-of-use of the interface to a usual house.
At the same time, I don't think anyone has ever yet been killed or seriously injured by horsing around with Visual Studio, or by having a bucket of variables dropped on his head.
But I have seen plenty of software that had the equivalent of "why do I have to turn on the lights in the bathroom to use the power outlets in the garage?"
My current apartment had an upside-down lightswitch. No reason for it, just it was installed upside down. In a bank with 3 other lightswitches which were right-side up. I've definitely seen that kind of thing in plenty of software. None of the prior tenants had done anything about it. They didn't even call support and get them to get it fixed. I, on the other hand, have a screwdriver, and now have a right-side-up lightswitch. Plenty of parallel there!
There have probably been plenty of times that the builder has kept a key to the back door, intentionally or not.
And last, but not least, in some software, letting the kids have their own key, so they can get in when they get home from school and you're still at work, can get very interesting, especially if you forget to lock up your video collection.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 2, 2008 at 7:42 am
I've helped build a few houses (my parents', sister's, uncle's, and a few others), as well as building several decks and what-not. The biggest difference I've seen is that once the plans are laid for a house, the only allowable changes are generally aesthetic. You can determine during the building whether you want to square off corners of the roof or just leave the simpler angle, but changing the entire angle of the roof is just far too costly.
In software, some major architecture changes may not be all that costly, though many often do result in increased cost to someone. Also, most people have seen enough houses to know what is possible and what they want, whereas in software, so many things are possible, including what has not yet been seen, that nailing down a final solution at the get-go is often difficult.
As with house construction, however, as a developer I would love if clients would take a more staged approach to building software. Instead of trying to add things into the foundation-laying stage, just develop further "remodels" or "additions" for later, when these can really be well designed. Of course, the difficulty here is that you now have to "wire" the application to be able to be easily upgradeable to include outdoor speakers and a deck when such things haven't been thought of before. In the end, some things have to be broken down in order to move forward, but at least you can plan that better with a solid construction and not worry about the whole thing crashing to the ground.
June 2, 2008 at 8:37 am
I recommend reading 'The Timeless Way of Building' by Christopher Alexander. This book is a theory of architecture based on a series of patterns, and laid the groundwork for the pattern-oriented movement in IT. It's a fascinating read, regardless of what you're thinking about building.
June 2, 2008 at 8:51 am
I find the analogy between developing software and building a house to be quite accurate, especially since I've done both!
I'm "self-taught" in both industries and have designed, written & implemented full scale applications in an I.T. environment and I physically constructed my own house (over 2K sq. ft. with an all wood basement).
Although I'm reputed to be a notorious "brain picker" when I'm trying to learn a new skill, I feel that the basic skill of being able to think through a problem/project in a logical progression (and recognize the potential constraints and short cuts during the planning stages) is the fundamental road to succeeding.
I did chuckle at your "loss of materials" comparison in the construction industry. Big tip! - If you're ever building anything with lumber and nails, pick up a sawzall (reciprocating saw). I was 4 inches off with a centering a door opening, and after cutting through the nails with the sawzall and relocating the door, I was only behind a couple of nails and a few minutes...
Gary Clinton
June 2, 2008 at 8:58 am
gary.clinton (6/2/2008)
I did chuckle at your "loss of materials" comparison in the construction industry. Big tip! - If you're ever building anything with lumber and nails, pick up a sawzall (reciprocating saw). I was 4 inches off with a centering a door opening, and after cutting through the nails with the sawzall and relocating the door, I was only behind a couple of nails and a few minutes...
Ah. I suppose that combines an ltrim and an rtrim in one convenient function 😉
Sorry, I'll get my coat......
Semper in excretia, suus solum profundum variat
June 2, 2008 at 9:02 am
This is a topic near and dear to my heart. I've been a professional developer for about 24 years, and before that was a building contractor for 15 years.
Having built hundreds of homes as well as hundreds of software projects, there is one difference that stands out between the two:
You can SEE what's being built on a construction project. You can stand on the site and see the carpenters are framing the second floor, that the plumbers and electricians are roughing in the basement and ground floor, etc. You can see whether the lumber package for the roof has arrived or not.
With software, you have coders sitting in cubes hunched over their computers (or nowadays, they're in some other country). You have NO idea what they're doing. Are they coding? Playing games? It's only during periodic reviews of their submissions or during status meetings that you find out what they've accomplished, and that assumes they're telling your the truth and not blowing smoke up your butt.
So, while there are many valuable parallels and much to be learned from them, at the end of the day it boils down to the ability to inspect progress that separates the two disciplines.
One useful thing I took from construction and applied to development, though. A crusty old framing foreman once told me that it doesn't matter how much layout you did during the day, even though it was vital for a successful project. What mattered is that by the end of the day you had SOMETHING "up and showing". He told me to be sure to frame at least one wall before leaving for the day, so that the superintendent could have something to see as he made his rounds. Chalk lines aren't visible from his pickup truck.
Applied to development, this means that as important as planning is, you also need to show real progress on the project each and every day. Make it easy for the project manager to see that you're contributing to the effort.
June 2, 2008 at 9:18 am
As a former General Contractor and the son of a builder, I too have a little experience with house building. Although I use the analogy of house building because it is most familiar to me. Of course, I could use some help to make the comparison to an interesting event that once occured during an extensive remodel. It seems the owner and his wife wanted to tour the destruction during the weekend to see how the work was progressing. The bathroom was nearly finished, but the brand new toilet was sitting in the middle of the bedroom...
I'm sure you can see where this is going.. er.. the 'direction this is taking'. Let's just say the owner's wife didn't have the courage to show back up at the job site. It just never occured to her that the toilet had to be connected to something to actually work!
----------------------------------------------------------------------------
"No question is so difficult to answer as that to which the answer is obvious." - George Bernard Shaw
June 2, 2008 at 9:23 am
Unfortunately software development projects are often like a box of chocolates. You never know what you're gonna get.
Could be like building a house, mall, car or any other project. You need to have skilled people involved who have been there before or you will think you are getting a package to calculate pounds of carbon produced per employee per year, and instead you get a Whitman's sampler.
Not all gray hairs are Dinosaurs!
June 2, 2008 at 9:26 am
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?
June 2, 2008 at 9:34 am
I had built two houses and I found a good contractor (or construction company) was very important. The second house I built I had a very good contractor. First we signed the contract and the contracting company actually put down the due date, it they were late, they had to pay us certain amount of money a day. Then they made sure the blue print was correct and they showed me every material they used. I went to check on them and all the contractor and the foreman were very helpful. Also they would fix everything the first year we moved in. That means a team of good developers always help to get the job done faster and better. The project leader or the manager is very important too just liked the foreman, the co-ordination of a project is important.
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 !
June 2, 2008 at 9:39 am
There are a lot of similarities in the process. The concept of different components working together. The frame being build on the foundation etc.
There are main differences that I see, one that was mentioned in the article. If you need to change anything it is much simpler and cheaper to change code than to rip out a concrete foundation. Although if you compare the design processes of building and software the difference basically disappears.
The other difference is that fact that the building is a static object. You know what the forces are at work on it and you know how it should respond to those forces (wind, earthquake etc). The unknown factors in software is where the difference lies. Exhaustive testing may limit this but in general the environmental factors are much greater than in a building.
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply