May 24, 2011 at 3:23 pm
Craig Farrell (5/24/2011)
It's a perspective. It's not a lack of requirements, it's limiting the requirements to have a starting point, and to allow for clarifications. It's working with business by giving them a simplified tool from the 'great grand master plan' to see if it even helps in their day to day job, or if you were all wet.
Exactly--and well said.
May 24, 2011 at 3:30 pm
djackson 22568 (5/24/2011)
john.richter (5/24/2011)
The problem was, as I see it, that the users were being asked to do a job of creation--envisioning the end result in one fell swoop. Anyone who's ever done any art--or programming--knows that creation has revisions. Very few get it right on the first cut, and the problems we address are not normally capable of being so well defined.I find that the reason the first cut is seldom correct is that the people who want a product to solve a need are unwilling to spend the time to determine what exactly they really want, and they seldom involve those who need to use the system.
The fallacy is to presume that methods like Agile require less testing and fewer requirements. In fact, if done right, they require more, just that they chunk them into much smaller pieces. You STILL end up having to test and meeet requirements at each gate.
The flaw with "traditional" requirements gathering is that it's VERY difficult to anticipate every single consequence of every single requirement, and impossible to anticipate how a raft of new requirements will interact with each other. So - it's often best to deploy often, and smaller pieces, so that the user gets something they want, test this something they want, and get benefit. Waiting until you have the perfect process means that a. you never deploy, b. what you deploy isn't relevant any more or c. the user requesting it is no longer here or no longer cares because you took too long to deliver.
Again, moving fast does NOT mean being sloppy in the process. It just means being smarter than before.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
May 24, 2011 at 10:02 pm
aphillippe (5/24/2011)
djackson 22568 (5/24/2011)
john.richter (5/24/2011)
Maybe I am not hearing what people are trying to say here, and if so I apologize. What I am hearing clearly does not make sense.I don't think anyone is advocating that simply reducing the amount of time spent on any single aspect of a project will be sufficient to ensure it's success. Any suggestion focusing on a single aspect (e.g. Time spent on any step of the process) cannot be made in a vacuum and must assume that other areas/aspects will pick up slack. In the case of reducing time spent on assessing business requirements and development, the benefit is reduced lead time and quicker iteration, with a resulting trade off of possible reduction in quality. It's a gamble that you'll get it right quicker (or at least keep the business happier until you get it right).
I think you summed it up well, but I do not agree with the theory that the gamble may pay off. I believe the gamble will always fail, except for those statistical anomalies where in spite of everything being done wrong somehow success accidentally occurs.
Dave
May 24, 2011 at 10:07 pm
Craig Farrell (5/24/2011)
djackson 22568 (5/24/2011)
Maybe I am not hearing what people are trying to say here, and if so I apologize. What I am hearing clearly does not make sense.Business users cannot design a tech spec. Ever. We can, but they can't read it and don't want to go plowing through your 150 page document of mock ups. No, really. They don't care. It's too much information at once, it's an overload. So you chunk it up to them, clean up the core, move to the next layer out, and proceed from there.
...
You may need some redesign. This process can create some very nasty applications to maintain because of the modularity of it and the shoe-horning that happens down the road. However, it's a lot better to the business users... even if changes eventually crawl to a stop.
This is it in a nutshell. One, business users should not be designing a tech spec, neither should developers. That is what analysts are for. They work between the end user and the developer and they speak both languages. Failure to use the correct people in each role causes failure.
Very nasty apps indeed!
Better to the business users? No. They may think it is better, but they are wrong. They don't realize it at first but when they do, as everyone has pointed out, they blame IS.
Dave
May 25, 2011 at 12:08 am
Gosh... I've seen this type of conversation come up over and over and people still haven't sussed it.
[font="Arial Black"]From the article[/font]
...but it's more important to get something done and in production than to have it perform and scale perfectly.
That's what I normally take exception to in articles/discussions such as this because people usually set the bar for performance and scalability way too low. Especially true for small companies but still true for large companies is the fact that when the scale of the underlying data grows, the code needs to be able to handle it because companies just can't afford the black eye such failures give to a company or IT department. Stop and think about when such performance or scalability failures occur... when the customer needs the performance and scalability the most.
The biggest problems I see with RAD (Rapid Application Development) and Agile (and I love/use parts of both) are simply not addressed by RAD or Agile. The single largest problem is that managers and C Level managers want product real bad... and they get it that way because process falls by the wayside in the face of aggressive schedule.
Yes! I believe in incremental releases and keeping process requirements to a minimum. Incremental releases are even more of a reason for performance and scalability to never fail... at least it should be that way. If you can't test it for performance and scalability before you ship it, you need to take smaller bites.
It's happened at every company I've worked for and it's happening again for some folks I'm working for. For the sake of supposed speed of development to meet an overly aggressive promised schedule (managers should be fired for that), they have GUI people creating their own SQL objects and writing their own database code (usually embedded code and not even sprocs). Although there are certainly some exceptions, I've found that GUI developers just aren't as good at SQL and object design as someone dedicated to the art. They've had several releases this year... and every single release has had both functional errors and some terrible performance problems with just a minor increase in scalability.
While it probably doesn't have to scale to a Peta-byte, code should scale. 10 rows of test data just isn't going to hack it. I don't normally refer to things as "nonsense" but the viral idea that one should not "optimize prematurely" is absolute nonsense to me especially since the people who have told me to avoid premature-optimization are also the ones that have code crash and burn in production. 😉
The perception of IT being slower than desired is a heck of a lot better than the perception (reality in many cases) that IT turns out crap code. Do it right the first time instead of 8 times like many companies do. It's a "Catch 22"... slow down, do it right, and the time you save on rework will allow you to speed up the next iteration. The lack of black eyes from the customers will make the boss pretty happy, too, even though (s)he may not be able to see that far ahead. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 25, 2011 at 12:49 am
So basically, speed things up by all means, use agile, increment releases etc. But it's all for nought if the other factors aren't right. Realistic expectations from management, getting business requirements right first time (or close to), making the right design decisions, good coding, good management of implementation/testing etc etc etc. Without any and all of the above getting it right, a quick project is just as likely to fail as a slow project. A rapid development style can only succeed in such an environment.
But the advantage is it takes you less time to realise things aren't going right and you have the flexibilty to make changes to get things back on course.
I guess peoples views on this topic are based on optimistism/naïveté or pessimism/experience. 😉
May 25, 2011 at 6:34 am
aphillippe (5/25/2011)
But the advantage is it takes you less time to realise things aren't going right and you have the flexibilty to make changes to get things back on course.
I've found that it's not really an advantage because most people also make the mistake of trying to save some of what they're started. Instead of it only taking twice as long, it takes 8 times as long (in my humble experience).
I guess peoples views on this topic are based on optimistism/naïveté or pessimism/experience. 😉
😀 That's actually a great comment and I hadn't thought of it that way before. It's funny that so many people equate experience to pessimism rather than to sage advice. It may be because when someone says "Not a bad idea but it won't work quite that way...", they MUST follow that up with "but I know what does. Here... Let me demonstrate.". Without going that extra mile, it IS just pessimism. I'll also admit that "how to make schedule" and "how to make the customer happy" is sometimes a bit difficult to demonstrate, though. Many times, such learning is accomplished by a failure and a very inappropriate "I told you so" instead of a more cooperative "Here's an idea that may prevent that problem in the future." To be effective, experience usually also needs to be humble.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 25, 2011 at 7:02 am
So to sum it up, this is about understanding what the user wants, having the time to implement it, test it, and prepare for the inevitable scaling and utter reversal of requirements that always occur.
You know, users really don't understand the why of things until they've actually gone through it. Of of our VPs is very conscientious and a *really* nice guy--but was completely clueless about the why of certain application features.
I spent a week educating him. Now he understands, and is helpful in moderating changes requested by users (read reigning in their impossible dreams). But we're a small company. I *am* the entire IT department: DBA, developer, computer repairman, computer buyer, and on and on.
And while I really enjoy the variety of work it does cut into the time spent on being a programmer/analyst (an old title that does exactly what it says on the tin :))
When I consider larger companies (and I've worked in Fortune 50s) the separation of duties and the political infighting are Godzilla-like alligators in the swamp they want us to drain.
Waterfall *sucks* as a design philosophy. Agile is no better. The problem isn't really with the models themselves, it's with *people*. Users never know what they want. IT doesn't know the user's job, so *they* don't know what the user wants either.
Blind leading the blind, anyone?
Prototypes aren't bad, they can help shape the user's fever dream into some kind of clarity. The problem is management confusing the prototype for a finished application that just needs "tweaking".
And it isn't. It really and truly isn't. *You throw the prototype away and start over!*
Sigh.
May 25, 2011 at 7:08 am
roger.plowman (5/25/2011)
So to sum it up, this is about understanding what the user wants, having the time to implement it, test it, and prepare for the inevitable scaling and utter reversal of requirements that always occur.You know, users really don't understand the why of things until they've actually gone through it. Of of our VPs is very conscientious and a *really* nice guy--but was completely clueless about the why of certain application features.
I spent a week educating him. Now he understands, and is helpful in moderating changes requested by users (read reigning in their impossible dreams). But we're a small company. I *am* the entire IT department: DBA, developer, computer repairman, computer buyer, and on and on.
And while I really enjoy the variety of work it does cut into the time spent on being a programmer/analyst (an old title that does exactly what it says on the tin :))
When I consider larger companies (and I've worked in Fortune 50s) the separation of duties and the political infighting are Godzilla-like alligators in the swamp they want us to drain.
Waterfall *sucks* as a design philosophy. Agile is no better. The problem isn't really with the models themselves, it's with *people*. Users never know what they want. IT doesn't know the user's job, so *they* don't know what the user wants either.
Blind leading the blind, anyone?
Prototypes aren't bad, they can help shape the user's fever dream into some kind of clarity. The problem is management confusing the prototype for a finished application that just needs "tweaking".
And it isn't. It really and truly isn't. *You throw the prototype away and start over!*
Sigh.
that's why prototypes need tobe as hugly as possible! Tho it doesn't work relly well for websites!
May 25, 2011 at 8:01 am
roger.plowman (5/25/2011)
Users never know what they want. IT doesn't know the user's job, so *they* don't know what the user wants either.
I guess getting a very clear and detailed picture of the busineess is the key. THAT is hard work, difficult and time consuming. Even for one who is in the business itself. Ask 100 practioneers and get 101 views of how the business works. Clear company processes will help but even these cover the big picture and the main tasks but not every detail (and there the trouble starts then latest). Rushing through that design phase will ruine the project.
If the requirements are made very clear and understood maybe it works if developers speed up lateron and accept to iron out some minor bugs as they go.
Just my 2cents who is sitting more on the users than the IT side.
brgds
Philipp Post
May 25, 2011 at 9:10 am
Jeff Moden (5/25/2011)
Gosh... I've seen this type of conversation come up over and over and people still haven't sussed it.[font="Arial Black"]From the article[/font]
...but it's more important to get something done and in production than to have it perform and scale perfectly.Do it right the first time instead of 8 times like many companies do. It's a "Catch 22"... slow down, do it right, and the time you save on rework will allow you to speed up the next iteration. The lack of black eyes from the customers will make the boss pretty happy, too, even though (s)he may not be able to see that far ahead. 😉
Are you looking for work, my director is looking for people who think this way! GRIN
Let's stop trying to make a few people happy today, let's start doing what is required to make everyone happy tomorrow.
Dave
May 25, 2011 at 9:39 am
djackson 22568 (5/24/2011)
roger.plowman (5/24/2011)
Shudder.Steve, that's a recipe for absolute disaster.
First, you're falling into the "get it out the door, we'll test it afterward" trap. Second, users will initially love it, and cause it to scale into failure, then abandon it and think IT are a bunch of idiots who can't program their way out of a paper bag.
As a developer first and foremost I'll tell you that all the agility in the world won't help you if the foundation isn't nailed down nice and tight. Systems analysts may be out of vogue, but the need for what they do isn't.
You're quoting from the Great Management Book Of Fail, and it makes my blood run cold.
IT is always too slow for everybody--but guess who has to take the blame when that hastily prototyped project scales into immobility and there's no budget to fix it?
Thanks! I was afraid, after reading the first few posts, that everyone had lost their mind! You have refreshed my belief that there are people who pay attention to history. I just am not sure if you captured the truth with terms like "absolute disaster". You need to be far more forceful!
WHAT ARE YOU PEOPLE THINKING!
Really? Have we not learned anything over the past 40 plus years? Did everyone forget that the world is more complex, business is more complex, requirements are more damanding, management is far less capable of understanding what their job really is, and providing the resources to make it happen? Need I go on?
How about this - let's replace the space shuttle with a vehicle that has not been tested, is poorly designed, and was developed with no analysis up front on what is requried. We don't need to spend money to make it air tight, who needs to keep the occupants alive! Get back to Earth in one piece, nah just rebuild it. Burn up in flight, we have 6 billion more people we can put on the next one!
I have said this before, and I will say it again - if you don't need it to work correctly upon delivery, you don't need it. Save your money. If you want something that works, spend the time and money to do it right.
Granted, there are various definitions of right, but the post that was sent out indicated that CIO magazine made suggestions that are proven failures. Let me see, does this increase or decrease my faith in the capabilities of CIOs in this country?
The space shuttle is a flawed analogy.
First, humanity spent centuries testing flying machines by dying in them or just looking foolish at best.
Once we had flying down well enough to have planes that didn't automatically crash if they ever took off, we had unmanned rockets that blew up as often as not, or more often.
Then unmanned satelites launched on rockets that might blow up, but they at least hit orbit.
Then dogs that were launched but never expected to come back alive.
Then manned ships that really couldn't DO anything, but had some hope of survival and return. (Ask Gus Grissom about the perfection of those vehicles. Oh wait, he died in one that caught on fire on the launchpad, so you'll need a ouiji board to ask him.)
Then manned ships that could actually DO something.
Then, over time, space shuttles that were designed by committees based on "we already spent so much money on that military spaceplane thing, we need to incorporate that in the design". And Challenger blew up because of an untested launch parameter (temperature of the launch facility). Columbia was killed by the basic design of the shuttle, because of that whole "we already spent so much on..." thing.
And now we're moving into an era where we don't even have a launch vehicle but will be outsourcing that kind of thing for "a short while".
So, all the waterfall methodology in the world was built on "trial and error" in reality, and even then it failed spectaculary to accomplish what the space program really needed in the first place. So, evolutionary design got the results we got, and waterfall killed a bunch of astronaughts and a schoolteacher but kept a bunch of beaurocrats employed.
Is either "best"? Nope.
But I really do hate that spaceshuttle analogy for "it has to be perfect out-the-gate so we'll design everything upfront". It's based on ignorance of history and the flawed idea that the Titanic really was unsinkable (to use another metaphore for the same thing).
- 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
May 29, 2011 at 11:40 pm
How about this - let's replace the space shuttle with a vehicle that has not been tested, is poorly designed, and was developed with no analysis up front on what is requried. We don't need to spend money to make it air tight, who needs to keep the occupants alive! Get back to Earth in one piece, nah just rebuild it. Burn up in flight, we have 6 billion more people we can put on the next one!
Do you mean to say that because of very good design upfront and lots of testing and lots of time and billions of dollars spent, not a single life has been endangered by your design upfront and waste billions methodology? Wasting billions in upfront design has stalled the space program, if we had practiced agile development in space we would have reached pluto by now.
May 30, 2011 at 3:58 am
umailedit (5/29/2011)
How about this - let's replace the space shuttle with a vehicle that has not been tested, is poorly designed, and was developed with no analysis up front on what is requried. We don't need to spend money to make it air tight, who needs to keep the occupants alive! Get back to Earth in one piece, nah just rebuild it. Burn up in flight, we have 6 billion more people we can put on the next one!
Do you mean to say that because of very good design upfront and lots of testing and lots of time and billions of dollars spent, not a single life has been endangered by your design upfront and waste billions methodology? Wasting billions in upfront design has stalled the space program, if we had practiced agile development in space we would have reached pluto by now.
A lot of dead astronauts, but most likely true. There needs to be a balance dependent on risk. A missed report won't end someone's world. A lack of enough fuel to come home can make a daughter cry every night for a lifetime.
Don't let Microsoft run my roadway, my niece would like to see her uncle next Christmas. At the same time, if her uncle doesn't have his report for the boss on time, but a few hours late, she still gets her presents.
I understand both viewpoints, but you're both comparing two incredibly different risk levels. We deal with information, not lives. The last time the two were equivalent (in my world, anyway) it was for a heart monitoring notification system at a hospital (with non-PC backups, that eternally nasty beep, among other things). You can be damned sure we were careful with that. The average business request is recoverable. A life isn't.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 13, 2011 at 7:21 am
The quote I've heard is "it's better to have 100% of a Mini [used to be a small, down-market UK car] than 90% of a Rolls Royce [hope you all know what one of those is]", meaning there's no point designing the most amazing system if you can only deliver a part of it, and that part doesn't do what the overall system was required to do. However, if you're going to produce 100% of a Mini, you need to get everyone to agree that the Mini does enough of what everyone wants, which requires someone analyzes what is required. After all, how can you even start to programme if you don't know what your programming is required to do?
Viewing 15 posts - 31 through 45 (of 52 total)
You must be logged in to reply to this topic. Login to reply