From Great Idea to End Result

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » From Great Idea to End Result

45 posts, Page 1 of 5

1 2 3 4 5 »»»

From Great Idea to End Result

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Monday, May 23, 2011 9:13 PM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 11:09 AM
Points: 31,416, Visits: 13,730

Comments posted to this topic are about the item From Great Idea to End Result

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #1113737

dallas-1069889

Posted Monday, May 23, 2011 11:40 PM

Grasshopper

Group: General Forum Members
Last Login: Sunday, April 21, 2013 10:26 PM
Points: 12, Visits: 103

Your products single greatest feature is release.

Post #1113768

aphillippe

Posted Tuesday, May 24, 2011 2:13 AM

Grasshopper

Group: General Forum Members
Last Login: Yesterday @ 3:48 AM
Points: 23, Visits: 278

I wholeheartedly agree. I'm lead developer on a new application for the bank I work for. We've been stuck in the familiar, drawn-out process of scope creep, revisiting specs half way through development etc. Development has been ongoing for months now and I can't help but feel that delivering an unfinished product as a starting point for further development would have allowed the business to make better decisions about the functionality required. One good decision I made was to break the large application into three smaller sections and agreeing to deliver each phase in a rolling deployment. This has made development much more focused (not quite the same topic but semi-relevant nonetheless).

I'm also interested in technologies like microsoft's lightswitch and will definitely be keen to try it out when it gets released. I hope these rapid development tools will let developers get to the situation described by Steve sooner.

I like the concept of final applications being seen as prototypes by the business but I have a feeling our risk review team (I work in a medium sized private bank) won't appreciate it too much!

Post #1113812

EdVassie

Posted Tuesday, May 24, 2011 4:03 AM

SSCrazy

Group: General Forum Members
Last Login: Today @ 7:57 AM
Points: 2,621, Visits: 2,758

I have worked in commercial IT since 1974 and have seen many approaches to getting applications delivered. 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.

The key feature of Agile - incremental development and delivery - can be an initial shock to the business, but at my place and many others I have heard about the business soon grow to love this process.

Ultimately product development is about delivering business value as minimum cost, time and risk.

Approaches such as Prince try to deal with these issues by identifying all issues before incurring the development cost. But too often Prince fails as the cost and time of identifying issues adds significantly to the project and Prince does not do enough to reduce the risks associated with the inevitable change that occurrs while the project is running. It may be a bold statement, but in terms of risk reduction the experience of many organisations is that Prince is not fit for purpose.

Agile expects change to happen. The position of the organisation in the market-place is continually changing, and business priorities change as a result. A product deemed critical to success in month 1 often needs to look very different by month 12 if that success is to be achieved. Incremental development allows the latest needs to be scoped, risk-assessed, developed and delivered before they become obsolete.

it may well be that a well organised development team will deliver much the same number of Function Points using Prince or Agile. Certainly this is what we feel. But we also feel the points delivered by Agile were produced in less time, with less analysis staff, and are what the business needs. The Prince points too often ended up being what the business thought they needed some time back, and not what was actually needed at time of delivery.

Hopefully nothing too controversial in all that... Smile

Author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2012, 2008 R2, 2008 and 2005. 25 March 2013: now over 23,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.

Post #1113860

Andy Warren

Posted Tuesday, May 24, 2011 6:10 AM

SSCertifiable

Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462, Visits: 1,384

Ed, I agree about Scrum, it's a very interesting formula.

I also agree about velocity. Being in IT isn't the easy job, trying to figure out how to do things quickly without creating a mess that you (or the next guy) will have to clean up, mumbling the entire time. It's not all our fault, but some of it is. I like to think we're getting better at it.

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #1113936

Schodoodles

Posted Tuesday, May 24, 2011 7:15 AM

SSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 24, 2013 9:48 AM
Points: 49, Visits: 153

I have to agree with Scrum as well - although I went through the training in my last role I jumped ship before doing too much.
I think it's success depends a lot on the management of the process, people adopting it and the politics being right in the organisation. There should also be enough documentation so that people are clear once agreed what is being developed. I've heard of a few examples of Dev's trying to worm their way out of things due to a post-it going missing or not enough detail.

Post #1113999

roger.plowman

Posted Tuesday, May 24, 2011 7:29 AM

Old Hand

Group: General Forum Members
Last Login: Yesterday @ 6:41 AM
Points: 317, Visits: 617

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.

Having said that, you can't allow feature creep either, and flexibility for future expansion isn't a luxury, it's "the only thing". Having been bitten by that bug more often than I care to think about I now ignore anyone who says "oh, that can't change, it's fundamental to *everything*. I just don't tell anyone I'm building flexibility into the design...

Ha.

You'd have thought 255 monetary denominations would have been enough for a USA only app too!

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?

Post #1114013

Mike Palecek

Posted Tuesday, May 24, 2011 7:36 AM

SSC Eights!

Group: General Forum Members
Last Login: Friday, May 17, 2013 7:26 AM
Points: 845, Visits: 688

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.

Post #1114027

EdVassie

Posted Tuesday, May 24, 2011 7:56 AM

SSCrazy

Group: General Forum Members
Last Login: Today @ 7:57 AM
Points: 2,621, Visits: 2,758

To avoid doubt, Agile does not mean deliver whatever state it is in. There is a lot of rigour around Agile so that you only deliver what is working, and that what you deliver meets a minimum acceptable feature set. There is also tracking of 'technical debt', so if you cut corners it becomes obvious what you have done and how it affects ongoing delivery velocity.

BTW, one of our teams has some metal ducting over their team area, and they clip any cards describing technical debt on to this with magnets. It graphically shows how this debt could fall on their heads if not properly fixed.

Author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2012, 2008 R2, 2008 and 2005. 25 March 2013: now over 23,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.

Post #1114045

john.richter

Posted Tuesday, May 24, 2011 7:59 AM

Grasshopper

Group: General Forum Members
Last Login: Wednesday, January 16, 2013 5:58 AM
Points: 16, Visits: 148

After about 25 years of this stuff, I'd have to say that my experience is that all successful application builds are "agile" regardless of name used on the method. The single track, up-front design methods are predicated on a chimera: No user community ever knows--or can know--exactly what the end product should do. They have dreams and thoughts and desires--some of which are spot-on, some of which are foolish, and all of which may seem perfectly reasonable on paper.

I recall one project in particular, an application to track customer claims (product deficiencies). There had been two previous attempts to write an application for this use, but the users were still tracking with spreadsheets, email, and conference calls. And not doing a very good job of it. Money got paid back to customers on claims, but root causes were not found. However, the job they did by hand was better than the (impossible to use) custom applications that had been written to the user's specifications.

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. To end this cycle of developing useless applications to spec, I (at first) refused their input on new features. I gave the developer strict orders to only examine what they did now, a quick and dirty use case, and automate that. This decision was about as popular as you can imagine.

Even so, within a few weeks the developer was able to deliver a first-cut program that automated the job they were doing by hand. At this point, with the application in use--and it was seized and used immediately--we opened the door to suggestions. A number of those came in--some useful, some not. The entire operation took only a few months (maybe a tenth of the time that had been wasted on previous attempts), and the product was successful enough that in about a year, the quality issues had been tracked and handled well enough that the application was seeing very limited use--there were barely enough claims to track.

This wasn't a pure application of any methodology, but it sure was agile. While a success, it wasn't perfect. I believe I am still remembered as the guy who told the users "no, you are not first going create list of feature demands." And the project took place in the usual swirl of too much to do, so it could have benefited from tighter supervision. The DBA at the time was also managing the department (guess who that was). Some of the things the developer slipped into his application and database shouldn't have been. Even so, it followed the rule of figure out the basics, get something working and built on some kind of a stable foundation, and then add to that. Time will then tell if more money needs to be spent.

This is not to run down all the various methods for capturing needs, laying out functions, and so on. And I do agree that “just get something out the door” is not the way to go. I’ve fixed too much crap for that. But there is a middle ground. No method, or lack thereof, substitutes for judgment.

Post #1114047

« Prev Topic | Next Topic »

45 posts, Page 1 of 5

1 2 3 4 5 »»»

Permissions