June 2, 2008 at 4:52 pm
Comments posted to this topic are about the item Software Comparison - Part 2
June 3, 2008 at 1:53 am
You realy think the legal profession has a way of working and a reputation that the IT profession should aspire to? Not in my book.
G
June 3, 2008 at 5:57 am
I must admit I'm scratching my head a bit here, regarding today's and yesterday's topics for discussion. The thing is that an analogy is there to illustrate a particular point, yet the analogies being put forward appear to have no such reason for their existence.
Subscribers can certainly praise the housebuilding analogy for the number of cross-over points it possesses, and detractors can certainly criticise it for those points where the analogy fails, but the real test of the analogy is whether or not it was useful in demonstrating the point someone was making. Yet no-one's making any points that need illustration. It's almost like the tail wagging the dog.
Surely, in these discussions, we're not really examining the analogies themselves, but instead exploring the parallels between software development and other careers, such as civil construction and law. If we strip away the analogy part, wouldn't that make said exploration rather more effective?
Sorry if this sounds negative, because it isn't meant to be. I really like the idea of finding different places where what we in IT do is practiced in different ways, not least so we can cherry pick best practices.
Semper in excretia, suus solum profundum variat
June 3, 2008 at 6:18 am
In defense of these topics:
I think that at some point we all wind up trying to rationalize our existence to the people who write the checks (among others). If we're not rationlizing our existense, we're certainly trying to provide explanations as to why certain dollar amounts are associated with our work and why certain levels of quality are worth those amounts. Having a variety of tools to provide such explanations may be as valuable as having a variety of tools to manage a database. Analogies hit home many times when facts don't.
OK - today's article:
The lawyer analogy is a good one, albeit limited. Whereas a good number of people have been involved in a building project of some kind (at least watching), much fewer understand the business of legal documents. Just the thought that we give some requirements to a lawyer and he comes back with a document that does the job even though we don't understand it may work for some. On the other hand, most people don't like lawyers, so it may not be a good idea to associate ourselves with them (my apologies if anyone out there is a lawyer as well as a programmer). Carpenters and builders are a much friendlier lot.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
June 3, 2008 at 6:28 am
So your ASP .Net friend is saying that all legal documents are perfect and have never been contested in a court of law? Please...
To the end user (customer), for the most part both legal documents and software code are not understandable which is why the attorney or software engineer was hired in the first place. But the end result will be clear when the legal document is exercised (somehow used) and the software is used. If the customer did not get the end result he expected (notice I said expected, not asked for), there will be a less than fully satisfied customer.
Software development goes back to the customer knowing and understanding what they want and then being able to communicate that to the developer, business analyst, or whoever.
I have worked on more than one project where the business users didn't understand their processes, or there were differences in the way management thought the processes worked versus how the end users thought the processes worked, and I have seen business management changes in the middle of a project where the new manager thought the process should work differently than the old manager did. So depending on who you talked to on the business side, you may get a different explanation of what they want (but this never happens, does it).
Do you think any of this might have an impact at the end of the project on whether the software is working as desired?
I would venture a guess that in the legal profession there is not quite as much variability because the outcome of a legal document has to follow set laws for most part. Our software has to meet what the customer tells us it does, and that can be anything.
If it was easy, everybody would be doing it!;)
June 3, 2008 at 7:31 am
Lawyers also get to use libraries and search old cases to cite for their own. When programmers try to reuse code its frequently called illegal (copyright, patent...). Ironically many lawyers sue for such things! If we could all share code as lawyers share case law, we would be in much better shape. I think the open source movement has made a big dent in many applications. But open source is very limited in scope. I'm not making excuses for IT, as we should be doing much better at project management and we should be looking at methods used in other industries. I an IT code library - like the script library here, would be extremely valuable. Maybe your lawyer friend can start reviewing case law on code sharing.
June 3, 2008 at 8:41 am
majorbloodnock (6/3/2008)
I must admit I'm scratching my head a bit here, regarding today's and yesterday's topics for discussion. The thing is that an analogy is there to illustrate a particular point, yet the analogies being put forward appear to have no such reason for their existence.Subscribers can certainly praise the housebuilding analogy for the number of cross-over points it possesses, and detractors can certainly criticise it for those points where the analogy fails, but the real test of the analogy is whether or not it was useful in demonstrating the point someone was making. Yet no-one's making any points that need illustration. It's almost like the tail wagging the dog.
Surely, in these discussions, we're not really examining the analogies themselves, but instead exploring the parallels between software development and other careers, such as civil construction and law. If we strip away the analogy part, wouldn't that make said exploration rather more effective?
Sorry if this sounds negative, because it isn't meant to be. I really like the idea of finding different places where what we in IT do is practiced in different ways, not least so we can cherry pick best practices.
I have to agree. The whole point of making analogies is that they explain something (which isn't understood) by comparing it to something else (which is understood).
Almost everyone has experienced a building of one sort or another, and is familiar with the idea of foundation, structure, rooms with various function, doors, windows, wiring, pipes, etc.
Very few are familiar with the inner workings of legal documents and cases (if they are, it's generally with the Hollywood version, which is almost as accurate as the version of computer programming in such marvellous, documentary movies as Swordfish). That lack of familiarity makes it a poor choice for most situations where an analogy would be helpful.
- 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 3, 2008 at 9:30 am
I probably didn't do a good job explaining the analogy, but I think that looking at other professions might help us decide if we should change the way we do things to be more like, or less like, other fields.
My point was more that lawyers do imperfect work, and we don't always understand what we get or like what we get, but we pay them. And if they need to revise something to better meet our needs, we pay them!
Perhaps that's why lawyers are disliked.
Should software be like that? should we just do our best, and if it's not right, continue to bill, saying the customer needs to better refine what we should do? It's different than building in that typically there we pay more when WE want changes, and if the builder hasn't followed our specs, they pay.
I'm not sure the legal profession is a great analogy, but there is something to compare here with the fuzzy specifications both groups get. Perhaps we want to differentiate software from these other professions and do a better job.
June 3, 2008 at 9:43 am
It seems everyone here really needs to learn about "Project Management"! The analogies are all similar because architecting anything, a house, bridge, ship, legal-case, finacial plan, software, etc. all use the same formal processes that only vary in the specifications and tools used to get the job done. Any valid PM could testify to this widely-known fact.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
June 3, 2008 at 11:07 am
Like some lawyers that work for a percentage of a settlement, maybe a software development contract could be structured such that the development firm gets a percent of the revenue generated by the software (or the calculated ROI for an internal IT project). Get enough of those contracts up and running, and you end up with a nice recurring revenue stream.:D
TroyK
June 3, 2008 at 11:24 am
Steve - OK. Good clarification.
P.S. Just tell me that used car salesmen aren't in your upcoming article list... :w00t:
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
June 3, 2008 at 11:24 am
What I am hearing in Steve's editorials and in the posts, is that we are still trying to find a way of dealing with the pain in software development. Many keep looking for answers in other more mature fields, but we still have not found a good mentor.
Yes, project management has helped, but it has not provided the magic bullet, and has created some new problems.
If your really interested in the subject, check out Scott Ambler. He has many interesting things to say about the lessons learned it this relativity new profession.
My own observation is that alot of the pain occures because software development requires a great deal of creativity and yet we try to pigeon hole it as an engineering field. Some of it is exacting, but some of it is very subjective.
June 3, 2008 at 11:34 am
The Laws of Manu were published in India about 200 BC. They are the oldest laws on record. Maybe when the oldest software code is 2208 years old, we will have developed a tried and true universally accepted method of charging for our services. 😉
Mia
Mia
I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
-- David M. Ogilvy
June 3, 2008 at 12:31 pm
Project Management is a big part of it, but it's also how we want to be perceived by other groups and people in general. I think IT has a fly-by-night, seat-of-the-pants, half-a***d attitude sometimes and builds some resentment from other groups in companies and clients.
I thought lawyers was an interesting comparison, but not the profession that I want to be compared to.
Also, no car salesman. Other white collar ones only, though I'm open to suggestions. Or guesses for the next 2 😉
June 3, 2008 at 1:08 pm
Steve Jones - Editor (6/3/2008)
Project Management is a big part of it, but it's also how we want to be perceived by other groups and people in general. I think IT has a fly-by-night, seat-of-the-pants, half-a***d attitude sometimes and builds some resentment from other groups in companies and clients.I thought lawyers was an interesting comparison, but not the profession that I want to be compared to.
Also, no car salesman. Other white collar ones only, though I'm open to suggestions. Or guesses for the next 2 😉
The main negative image I run into in non-IT when complaining about IT, is that IT personnel tend to communicate poorly with non-IT personnel.
Next after that, is that software doesn't do what's needed, and getting IT to make the software do what's needed, is not so much comparable to pulling teeth as it is comparable to be dragged behind a moving vehicle on a gravel road.
As far as the used-car-salesman analogy goes, I think a valid statement that both tend to promise a lot and deliver less could be made in many cases. Rarely does an engineer planning a bridge wax eloquent about how his new bridge will cure all of mankind's maladies and bring in a golden age of new, improved humanity. IT departments often seem to making that kind of promise. "It'll get 50 miles per gallon, and has European-style tail-lights, and we've done a 500-point check on the engine and the rest of the car and it's better than when it came off the assembly line, and it looks good to chicks, and will lower your insurance payments, and will improve your self-esteem", seems pretty comparable at times to, "a paperless office will lower cost-of-business, speed up line-of-business, make training and hiring less expensive, increase productivity, make the managers more masculine, the secretaries more feminine, reduce global warming, and allow business-continuity in the case of nearby supernovas destroying all life on Earth". (Okay, I'm taking this a tiny bit further than any real IT department... a tiny bit. And, for the sake of humor, yes, this was deliberately sexist.)
There are IT depts that deliver what they promise, when they promised it, and where it actually does what the business actually needed. From what I've experienced and heard, they are quite rare.
Part of the problem with a comparison with lawyers is that lawyers are often operating under constraints such as opposing counsel, precedent, etc. Software rarely has to comply to standards from before the 1800s, unless it touches on legal affairs. There is very rarely someone whose job is very specifically to make your software/project fail.
Software development is an engineering discipline. I can't imagine a circumstance under which a piece of code would succeed or fail to compile and run based on which manager is on duty that day, but there are divorce lawyers who pay attention to which judge is seated that day, because it makes or breaks the case.
Can you even imagine that something like jury selection would matter to software? "If selected for the beta testing, would you be able to give the software a go-ahead?" vs "If selected for the jury, would you be able to give a guilty verdict, depending on the evidence presented?"
I can see where someone would look at the level of detail both jobs need to pay attention to. There are software standards, which can be quite complex and verbose, just as there are legal standards. Both tend to deal with documents that most people wouldn't recognize as "easy to read". But I really don't think it clarifies anything for anyone to compare the two, unless you're very specifically explaining software development to a lawyer.
- 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
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply