Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

The Software Comparison Expand / Collapse
Author
Message
Posted Saturday, May 31, 2008 12:49 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:25 AM
Points: 33,267, Visits: 15,433
Comments posted to this topic are about the item The Software Comparison






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #509494
Posted Monday, June 2, 2008 2:09 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, September 12, 2014 7:14 AM
Points: 1,049, Visits: 3,007
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.....



Semper in excretia, sumus solum profundum variat
Post #509691
Posted Monday, June 2, 2008 5:11 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, September 29, 2008 5:10 AM
Points: 78, Visits: 43
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.
Post #509745
Posted Monday, June 2, 2008 6:32 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, January 29, 2014 7:19 AM
Points: 153, Visits: 569
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.”
Post #509781
Posted Monday, June 2, 2008 7:27 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
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
Post #509834
Posted Monday, June 2, 2008 7:42 AM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, March 17, 2014 8:51 AM
Points: 42, Visits: 104
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.
Post #509852
Posted Monday, June 2, 2008 8:37 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Saturday, February 14, 2009 10:04 PM
Points: 234, Visits: 74
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.
Post #509901
Posted Monday, June 2, 2008 8:51 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 5, 2010 7:29 AM
Points: 4, Visits: 29
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
Post #509920
Posted Monday, June 2, 2008 8:58 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, September 12, 2014 7:14 AM
Points: 1,049, Visits: 3,007
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, sumus solum profundum variat
Post #509922
Posted Monday, June 2, 2008 9:02 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, April 5, 2014 9:42 AM
Points: 27, Visits: 41
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.
Post #509927
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse