May 24, 2011 at 10:04 am
Too much philosophy! :w00t:
I've turned out projects in a week and continued to build on them.
I've worked on projects for months, adding new ideas and requirements, and still we continue to add functionality.
I've created great projects that the users won't use and IT has ended up using the app and the company has eliminated the positions of the people that would have used the app.
The bottom line: IT's always IT's fault. Suck it up and get back to work.
(Dang, it's only Tuesday and my cynical chip is over heating...:cool:)
May 24, 2011 at 10:38 am
Interesting topic today. I know of some shops that adhere to the principle of get it out and come back and enhance later. They aren't shooting for perfection with the first release. That can be good or bad. I think that project documentation and scope come into play with that.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 24, 2011 at 11:57 am
Steve Jones - SSC Editor (5/24/2011)
I haven't said don't test it or throw it out the door. The decision to move something out before it is complete doesn't mean that the parts that are complete don't work or aren't tested. They're working, but not necessarily adding all the functionality. Note that I said that management has to buy in and either invest more in what they want or throw it away.
The past is the past, and continuing to cling to the idea that we just get done and move on, letting the work limp on isn't acceptable. That's the message that you want to bring to management and have users bring up as well.
Color me cynical but that never happens. Management (or C-level) will always cut the developers off at the knees. The project will never have time for adequate testing, it will be "that's good enough, they needed it yesterday, now release it".
Web-based programs are particularly prone to this which is one (of many) reasons web programs are so insecure. But desktop programs aren't immune, though usually they don't have a decent time-budget either.
Then there's the fact that developers don't understand SQL Server, DBAs don't understand development, and everything takes 5 times longer than it should... (sigh)
As I said, I'm a bit cynical.
Couple that with "it's faster to do X" and the managment types hear "we can cut the testing budget in half".
Maybe "bitter" is a better word than "cynical"... (chuckle)
May 24, 2011 at 12:27 pm
roger.plowman (5/24/2011)
Couple that with "it's faster to do X" and the managment types hear "we can cut the testing budget in half".
...and: "We'll write the documentation later!"
May 24, 2011 at 12:34 pm
EdVassie (5/24/2011)
The agile methodology using Scrum (and its variations) is by far the most effective way I have seen for delivering useable value to the business.
I'm not a developer, but from what I've seen, agile development requires a lot of feedback from the business owners. Is this the case, and does it get to be a problem if the end users can't give you enough time?
May 24, 2011 at 12:36 pm
Peter Maloof (5/24/2011)
EdVassie (5/24/2011)
The agile methodology using Scrum (and its variations) is by far the most effective way I have seen for delivering useable value to the business.I'm not a developer, but from what I've seen, agile development requires a lot of feedback from the business owners. Is this the case, and does it get to be a problem if the end users can't give you enough time?
It's definitely a problem if you don't get feedback from end users.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
May 24, 2011 at 1:02 pm
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?
Dave
May 24, 2011 at 1:04 pm
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.
Dave
May 24, 2011 at 1:07 pm
Steve Jones - SSC Editor (5/24/2011)
mpalecek (5/24/2011)
I have to agree with roger.plowman. I am in a small company with an equally small staff.Projects routinely get started with a good plan and scope. After a short period of time the decision is made to just "get it out", with or without half of the requested features (usually reporting or administrative maintenance). Once it is out and working (no matter how well or not) we move on to the next greatest thing. We then spend to much time fixing/training/reparing data/etc.
That's not what I advocated. Go back and read my piece. Management has to invest in those projects that they want to grow and expand.
Steve, that may not be what you intended to advocate, but I do not believe you conveyed what you intended if that is the case.
Dave
May 24, 2011 at 1:09 pm
Peter Maloof (5/24/2011)
EdVassie (5/24/2011)
The agile methodology using Scrum (and its variations) is by far the most effective way I have seen for delivering useable value to the business.I'm not a developer, but from what I've seen, agile development requires a lot of feedback from the business owners. Is this the case, and does it get to be a problem if the end users can't give you enough time?
To the end users and their managers, enough time is defined as 5 minutes. Part of that 5 minutes is them getting coffee. The other part is them talking on their cell or answering emails on "things that are really important".
Dave
May 24, 2011 at 1:48 pm
To djackson 22568--what you say might be. However, in this case, they had spent a great deal of time, an inordinate amount of time, twice, and still came up with requirements for a product, that when produced to their specifications, was not what they needed--or wanted.
May 24, 2011 at 2:27 pm
john.richter (5/24/2011)
To djackson 22568--what you say might be. However, in this case, they had spent a great deal of time, an inordinate amount of time, twice, and still came up with requirements for a product, that when produced to their specifications, was not what they needed--or wanted.
OK.
So the answer is to spend less time, which will somehow allow them to miraculously figure out what requirements are truly needed? No. The answer is to do proper requirements elicitation up front, which is rarely done properly. Carnegie Melon has an outstanding paper that explains why projects fail, and those who read it and implement their suggestions are far more successful than they were prior to.
It isn't about how much time you spend gathering requirements. There is no right answer to that. Each project is different.
It is about the quality of the requirements. If they spent an inordinate amount of time and failed, they either did not spend enough time or they did not gather the requirements.
I once worked for an organization that believed employees were not doing enough to move work through the system. Their answer was to cut worked hours per task. It didn't work. You can't decide that the reason the product failed was because you spent too much time analyzing the requirements.
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.
Dave
May 24, 2011 at 3:03 pm
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).
May 24, 2011 at 3:18 pm
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.
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.
It's the equivalent to prototype more, waterfall less. Many projects fail for the reasons you stated, agreed. More projects fail because they never get in front of a client because you're trying to handle every minor inch of what 'might be'. In our own little sql world, we don't optimize to perfection, it takes too much time except on severe cases. We optimize to good enough.
The idea is to kernel and grow a used tool so that your core attributes aren't skewed from the beginning of a massive waterfall where your core is flawed so you end up rebuilding the entire thing. Get the core right, move forward with more resources if it's usable. If not, dump it for a low cost to return and move on to the next thing.
Mock up screens are great, but nothing really hits users like a usable tool. Getting that tool in front of them is paramount, so you can really start finding out the requirements. For example:
Business: "We need a document storage tool!"
IT: "Okay! What are we storing?"
B: "PDFs"
IT: "Wha? you can already store pdfs... it's called a hard drive."
B: "Oh, we want to associate a number of PDFs with each other"
IT: "That's called subfolders."
B: "And we want to be able to ship these documents to the associated client in x tool."
IT: "AH! Now we have a project. So, you want to pull up a client, select the associated pdfs, and then ship, right? Checkboxes work for selection and your personal email work for sending?"
B: "Yeah!"
IT: Codes a while. Create little form, associate to server data, create something that browses the file system. Takes about a week.
B: "Great! YEah!"
1 week later
B: "Errr, ummm... yeah, not what we really wanted. We needed it to zip and FTP it."
IT: click click click...
B: "Great Yeah!"
1 week later... Etc.
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.
Can it bite you in the arse down the road? Of course. You had no idea that the next module was expecting a million rows and your 'good enough' was for 10k. That's okay, though. You accept that risk when you use this design methodology. 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.
Using this method I usually recommend a two year rule. You use this prototyping style of delivering to a client/business all the necessary functionality for a tool for around two years. Then you step back, figure out what it's actually done, THEN tech-spec it. Now you waterfall plan it properly into a coherent whole instead of a hodge-podge of add-ons, but purely from the tech side. Business has their tool, tech eventually cleans up the work.
It's simply a tradeoff. Work and ROI now for a debt later, but projects that actually are a failure from the business side because of functionality failures or a lack of clear need or even that the tool doesn't speed them up are roadkilled as quickly as possible, keeping assets where they're needed, on the important tools that facilitate the business.
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
May 24, 2011 at 3:19 pm
djackson 22568 (5/24/2011)
john.richter (5/24/2011)
To djackson 22568--what you say might be. However, in this case, they had spent a great deal of time, an inordinate amount of time, twice, and still came up with requirements for a product, that when produced to their specifications, was not what they needed--or wanted.... 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 know. I've been in this discussion a few times and invariably get accused of not wanting to plan. I don't ever recall saying that. But what I do say often gets such a visceral reaction that the conversation usually ends. Eisenhower is reputed to have said that "In preparing for battle I have always found that plans are useless but planning is indispensable." I’m not touting Eisenhower, but here he had a point. I think it's the key to successful development. To some, changing the plan is anathema. I say, if you know what you're doing, changing the plan is key to success--just as knowing when the plan (and planning) are junk, and it’s time to bail out. To push the analogy a little further (and I hope not past breaking), there’s little point in demanding one follow the detailed plan that ends at the bunker in Berlin if you’ve not a working application to get on the beaches at Normandy. Moreover, the application planned for Normandy will need to change under fire--but it’s that piece that has to come first, and it’s needed regardless. Not to say one shouldn’t consider what might happen at Berlin, but printing on the map which platoon is on which street corner is a waste. Now, maybe I’ve pushed the analogy too far or in the wrong direction, but there is a valid concept here. I still stand by my word that every successful development project is agile--note, that is lower case, not upper--as in light on its feet and able to change. People on those projects have dealt successfully with changes whatever they called their method. Plotting the application in general, and then planning the application core in sufficient detail and building those core functions, getting that core in use, refining as needed, and then building out as requested or required is a very workable. It gives value back quickly and quickly indicates if more investment is reasonable. This may change only slightly the effects of bad management, overloaded teams or unfunded support, but I think the change is in our favor.
Viewing 15 posts - 16 through 30 (of 52 total)
You must be logged in to reply to this topic. Login to reply