Comments on: Natural selection in IT http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/ Strong opinions, weakly held Mon, 17 Jun 2013 21:27:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Jason Neylon http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2575 Jason Neylon Tue, 14 Sep 2010 13:57:39 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2575 When faced with expanding an area of our business recently we actively encourage the team to use excel and access instead of building software for them. The business area was new to everybody so the initial requirements we had were based more on speculation than knowledge. When they were up and running (and making money) we started building software based on what the access databases and excel spreadsheet they were using. I talk about our approach a bit more here: http://jasonneylon.wordpress.com/2010/01/10/the-first-rule-of-building-software-dont-build-software/ When faced with expanding an area of our business recently we actively encourage the team to use excel and access instead of building software for them. The business area was new to everybody so the initial requirements we had were based more on speculation than knowledge. When they were up and running (and making money) we started building software based on what the access databases and excel spreadsheet they were using. I talk about our approach a bit more here: http://jasonneylon.wordpress.com/2010/01/10/the-first-rule-of-building-software-dont-build-software/

]]> By: Terry http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2574 Terry Sat, 11 Sep 2010 10:49:13 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2574 I agreed with everything up to this point: "Software is easy. Requirements are hard." It should say: "Software is hard. Requirements are hard." http://mdmstudios.wordpress.com/2010/08/28/programming-will-never-be-easy/ I agreed with everything up to this point:
“Software is easy. Requirements are hard.”
It should say:
“Software is hard. Requirements are hard.”
http://mdmstudios.wordpress.com/2010/08/28/programming-will-never-be-easy/

]]> By: Harry Steinhilber http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2573 Harry Steinhilber Fri, 10 Sep 2010 00:01:41 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2573 Absolutely agreed. Especial since I am in this exact situation right now: trying to convince the company to allow a "rewrite" of an Access application that needs to be rewritten as a real IT supported app. It serves its purpose wonderfully, but has outgrown what Access can reasonably deliver. Absolutely agreed. Especial since I am in this exact situation right now: trying to convince the company to allow a “rewrite” of an Access application that needs to be rewritten as a real IT supported app. It serves its purpose wonderfully, but has outgrown what Access can reasonably deliver.

]]> By: phat shantz http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2572 phat shantz Thu, 09 Sep 2010 14:08:11 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2572 As an applications architect I am constantly offended by the arrogance and elitism exhibited by IT staff regarding these "unsupported" applications. From their time in books 'til their ascendancy to control, engineers insist they can perform their duties without knowing what their clients do for a living. This leads to humorous and disastrous results like Fortune 100 companies where more than half the automation is written by "amateurs." It also leads to software solutions that have more input from the IT staff about how things "aught to" work rather than how the staff in other departments insist they already do. Walking into a requirements assessment with an agenda leads to the incomplete analysis, misunderstood needs, and incomplete designs that characterize software failure in the large organization. After the experts get it wrong, the novice will use the sticks and rocks already laying around to build what s/he can. In the shadow of the latest IT accomplishment, look for the mushrooms of desperation. You will see them every time. Takeaways: Lesson 1: If the expert won't do it right, the novice will. Lesson 2: The expert isn't. Lesson 3: Maybe that business education is worth more to IT than you thought. The hardest lesson is this: that IT has had the authority and tools for control but have, historically, misused and under-served their clients. It may well be that IT never understood that technicians work for everybody else in the company -- not the other way around. I have always felt that a survey of "client supported software" that finds more than a few user-created-solutions should lead to a reorganization of IT, a new CIO, and a fundamental awakening in the IT staff. I agree with everything in the commentary and would add that the overall "requirement" gained from the sheer number of "client-supported applications" mentioned is that IT must learn to listen. It's a good bet they aren't. As an applications architect I am constantly offended by the arrogance and elitism exhibited by IT staff regarding these “unsupported” applications.

From their time in books ’til their ascendancy to control, engineers insist they can perform their duties without knowing what their clients do for a living. This leads to humorous and disastrous results like Fortune 100 companies where more than half the automation is written by “amateurs.”

It also leads to software solutions that have more input from the IT staff about how things “aught to” work rather than how the staff in other departments insist they already do. Walking into a requirements assessment with an agenda leads to the incomplete analysis, misunderstood needs, and incomplete designs that characterize software failure in the large organization.

After the experts get it wrong, the novice will use the sticks and rocks already laying around to build what s/he can. In the shadow of the latest IT accomplishment, look for the mushrooms of desperation. You will see them every time.

Takeaways:

Lesson 1: If the expert won’t do it right, the novice will.

Lesson 2: The expert isn’t.

Lesson 3: Maybe that business education is worth more to IT than you thought.

The hardest lesson is this: that IT has had the authority and tools for control but have, historically, misused and under-served their clients. It may well be that IT never understood that technicians work for everybody else in the company — not the other way around.

I have always felt that a survey of “client supported software” that finds more than a few user-created-solutions should lead to a reorganization of IT, a new CIO, and a fundamental awakening in the IT staff.

I agree with everything in the commentary and would add that the overall “requirement” gained from the sheer number of “client-supported applications” mentioned is that IT must learn to listen. It’s a good bet they aren’t.

]]> By: Martin Jul http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2571 Martin Jul Wed, 08 Sep 2010 21:04:48 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2571 You may be interested in the statistics on how hard it is to get requirements right. In "How Scrum Reduces Rework" the data from an actual project indicates that 9 out of 10 causes of rework are related to misunderstandings, missing requirements and changed requirements - not coding errors etc. The article is here: http://community.ative.dk/blogs/ative/archive/2010/03/25/what-is-the-benefit-of-scrum.aspx All the best, Martin (Tw: @mjul) You may be interested in the statistics on how hard it is to get requirements right. In “How Scrum Reduces Rework” the data from an actual project indicates that 9 out of 10 causes of rework are related to misunderstandings, missing requirements and changed requirements – not coding errors etc.

The article is here:
http://community.ative.dk/blogs/ative/archive/2010/03/25/what-is-the-benefit-of-scrum.aspx

All the best, Martin (Tw: @mjul)

]]> By: Ollie Riches http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2570 Ollie Riches Wed, 08 Sep 2010 20:44:20 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2570 'You rewrite the code to build the system right, you characterize the existing application to build the right system.' You can never build the system right, only better... ‘You rewrite the code to build the system right, you characterize the existing application to build the right system.’

You can never build the system right, only better…

]]> By: Alper http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2569 Alper Wed, 08 Sep 2010 19:46:48 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2569 Agreed. Agreed.

]]> By: jdn http://lostechies.com/jimmybogard/2010/09/08/natural-selection-in-it/#comment-2568 jdn Wed, 08 Sep 2010 16:00:57 +0000 /blogs/jimmy_bogard/archive/2010/09/08/natural-selection-in-it.aspx#comment-2568 Ditto. Exactly. +1 Ditto.
Exactly.
+1

]]>