July 7, 2008 at 9:12 am
And those cars aren't perfect. There are "features" on them that don't work. Browse the recall lists and you might be surprised how many things need to be fixed. If you buy a new car, you get notified, if you buy used, > 1 day old, you don't hear about them.
We've had 3-4 "fixes" required for a couple cars, which involved setting appointments, dropping off the car (downtime) and then picking it up.
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
July 7, 2008 at 9:50 am
Interesting to read through people's description of Agile development, yet never use the term. Build, test, release (alpha, beta, release). The beauty of building software (as opposed to building cars), once you've figured it out, it's just a matter of typing. Thus, agile was born. You iterate through the development cycles until somebody states," I think it's good enough."
Moving past my observation of a group of people discovering what Agile is, and onto a real point-
A key political factor of deciding to release and whether it's "good enough" is to not expect management to honor a follow up to a release. Holding that release hostage to ensure that critical fixes, features make it in, is (sadly) sometimes necessary. It depends on the integrity of management, your experience with your management and trust in your managers must factor into the equation.
As you can guess, I've been put in this situation and have had to live with the consequences of "working around the bug" for years.
July 7, 2008 at 12:01 pm
Being a developer in a company unit of some 600 potential users of a application we start out by selecting a group of users ( 2 to as many as 10) and in discussions arrive at what the application should do, or if the job is to enhance an existing application what the enhancements should do. We then rank these requirements in priority order. We formalize the results of the discussions in a written requirements document and ask all of the selected user group to sign as originators of the requirements. Our objective here is two fold. First to get the requirements in writing which can be understand by the user(s) and the developer(s). Second to develop a feeling of being a team. Most of the time I think that team spirit is critical. After development we pass the "product" to QA for testing. In case of an enhancement as long their are no bugs that adversely effect existing functionality, and no bugs that corrupt data in any part of the application and QA lists any bugs detected as minor we then select a second group of users and ask them to run it and report their comments/complaints/suggestions. As long as this group reports only "I wish" items, and states that they would like to run this application in place of existing procedures then it is released to the general user population with an explanation of minor bugs, work arounds if viable, and what parts of the original requirements have not been implemented and a guess (estimated) time to include what is missing or fix those minor bugs. I believe the key to our techniques is the team spirit originally created. It is rare when we hear / read complaints such as "this blankety blank app sucks / does not work", what we will hear is comments such as "We have a problem" note the key word We, unlike Microsoft being castigated by those who hate MS, or those who need an excuse to explain poor workman ship to their bosses.
So yes it is a judgement decision, but the combined judgement of many individuals all with a vested interest in making the product function properly
July 7, 2008 at 12:07 pm
I've been doing what you call Agile for years, and it's worked well. It's a great evolution from the waterfall model.
I think MS has moved to this area in many ways, and in talking privately with engineers, they're entirely confident they can make substantial changes every 3 years. However they have a huge surface area, much larger than most of ours, and many more people to coordinate. So I think they'll have more bugs.
I want to see more stability from them. I think that, along with better performance, will sell more products than a few new features. But that's a separate debate.
I think that this is a decision you make on each individual item, and some will be good decisions and others perhaps bad. It's quite a balancing act to deal with and I'm glad I'm not a part of it.
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
July 7, 2008 at 4:15 pm
Well we have to apply DBA reply #2 (#1 being "No"), "it depends." For example, search for Vista 64 bit and 4 gig memory. If that bug got on the the release-anyway list, it's a crime. If it's a minor part of larger packages, I don't have a problem with it.
July 8, 2008 at 3:48 am
There is no perfect software, just some guidlines to follow:
1- Dont release a new feature until you test it.
2- Service the software in a reasonable time period. Clients will be happy when they know that you are there to service their product in a timely fasion. Your appraisal would be based mostly on that.
3- Hire good developers, Fire bad ones who refuse to learn
July 8, 2008 at 10:12 am
I'm not sure it's as simple as #1. A "feature" might be quite large and have many parts. What if one doesn't work as expected, or perhaps not as desired?
I definitely think there are cases where you might release something that's not quite done.
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
July 9, 2008 at 12:44 am
Yes, Features can be whole modules and can be quite complex.
We are supposed to test on a given set of scenarios or "testing paths"
Basic testing paths should pass before a new release, else, we are asking for trouble.
But you are right, this is not always the case, and sometimes we do a new release without proper testing due to time or other constraints. This is a very dangerous approach. If we take this approach, programmers/developers will have to play the role of firemen (when it crashes, fix it) and its a never ending loop.
I say, let professional testers test as much as they can and decide if a product is ready or not versus a certain set of acceptable rules.
programmers are bad testers (don't let them test)
July 9, 2008 at 12:52 am
sack bad dbas too hehe
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply