July 15, 2009 at 10:33 am
hmmm ... get it right the first time - like NASA !
http://www.sqlservercentral.com/articles/Editorial/67315/
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
July 15, 2009 at 10:52 am
Let's divide that 80/20 into functionality and correctness, hmm?
Provide 80% of *either* and you deserve to get fired.
Especially if 20% of the functions have some kind of problem, even small ones.
There's a world of difference between a phased development project and delivering 80% of what was spec'ed Saying "Ok, in Phase 1 we're going to deliver A thru J, in phase 2 K - P, etc" is perfectly acceptable. But if you say "Phase 1 delivers A-J" and you don't actually deliver H, I, and J they're going to be *angry* with you.
And rightfully so.
No, delivering 80% of promised functionality is a non-starter. Because then you haven't actually fulfilled your promises. Managing end user expectations is part of the job in systems analysis.
July 15, 2009 at 12:31 pm
Requirements not clearly defined. I bet a lot of people could right books about that. Anyhow, I heard years ago that Bill Gates did not run a software company, but a marketing company. Thus (in my opinion) it mattered less how well it worked, but how well does it look.
So taking a committee and a lot of time to figure out how do we want to shut down menu to look does not seem unreasonable. Then what features to include, exclude.
I have worked with software design teams in regards to entertainment software. As they say, everyone has an opinion on how it should look and work.
July 15, 2009 at 12:52 pm
The trick is knowing how it will be used, and putting in error traps for expectable mistakes and misuses. The things you can't protect against are the things you don't imagine in the first place. In other words, if you know you need alpha characters in a field, you can put in a test to make sure no one enters non-alpha characters, etc.
That said, the problem is much harder with multithreading than it was in the old days with single user per machine (or multiple users using the computer with interleaved processes). I have a lot of respect for the people at MS who work hard to get releases out to correct bugs as they are uncovered.
July 15, 2009 at 1:08 pm
No matter how large or small a software project is things can go well and on time.
Testing on a modular level can be quite elegant and efficient. Take Unix and the various *NIX variants. The key to this software and it's testing (and success in both I might add) is the following test conditions that are applied to each discreet piece of software:
Does it 'work' with the right input
Does it 'work' with no input - of course providing diagnostics
Does it 'work' with the wrong input - providing diagnostics and nothing else
(I believe that these criteria for testing came out of BSD Unix almost 2 decades ago. It is one of the most secure *NIX variants in the world today !!!)
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
July 15, 2009 at 8:08 pm
Well,
I think in any software development project, you need to think about the 3 dimensions: time, quality, and cost. In most cases, you will need to compromise one over another. If time is the most important factor then you may want to ship the product even with 80% of the functionality and then send the full featured product later on. In this specific context, I am fully agree with Steve. Especially when the 20% of the features are not critical to the function of the whole system. This is more likely to happen with internal development department.
Of course, there are some cases in which quality and full features are more important than the time delay. A lot of game developers announce that they will postpone the release date of the game just because they want to add the functionality or use the latest technology. It is more about marketing values (or other strategic decisions) to them. Anyway, you can't send patches for Wii games for example. But you still can sell new version/expansion pack of the game.
Ivan Budiono
Ivan Budiono
July 15, 2009 at 9:36 pm
With the shrinkwrapped software and inhouse/3rd party code I've seen coming out lately, I'm pretty sure that over-engineering isn't a wide-spread problem. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 15, 2009 at 11:39 pm
I think that the componentization of software has a role to play, a programmer does not have the big picture, in the earlier days one was responsible for the entire functionality being delivered, now we program for objects without knowing too much of its actual usage.
July 20, 2009 at 1:19 pm
roger.plowman (7/15/2009)
There's a world of difference between a phased development project and delivering 80% of what was spec'ed Saying "Ok, in Phase 1 we're going to deliver A thru J, in phase 2 K - P, etc" is perfectly acceptable. But if you say "Phase 1 delivers A-J" and you don't actually deliver H, I, and J they're going to be *angry* with you.
And rightfully so.
No, delivering 80% of promised functionality is a non-starter. Because then you haven't actually fulfilled your promises. Managing end user expectations is part of the job in systems analysis.
That may be, but real life does not always allow for us to deliver what we promised, on time. Stuff happens, like it or not. So in that situation would it be better to deliver the 80 percent (presuming it's tested and working correctly), or deliver nothing until you can get the reamining 20% working. At least in the former case the customer receives value, maybe not all they expected, but SOMETHING, which may well be good enough for most of what they need, which is frankly in my mind a lot better than getting nothing and having to wait.
The other thing is that if given the 80%, (Presuming it's the RIGHT 80%) the customer may well be quite delighted with much of what they've gotten, and even say 'hey, let that other 20% slide for a bit, because we've these two other things that came up that we need a lot more."
Agile Development practices have a lot to say in this area, and I agree with most of it. It's very difficult to plan perfectly no matter how much time you put into it. it's even sometimes difficult for the customer to explain and spec what they really need. So you are a lot better off to work with the customer and stack rank all the stuff they want, work on the most important stuff first, deliver that and get feedback, and then adjust the plan for the remaining work and deliver the next chunk.
You can spend a ton of time overthinking how someone is going to utilize a product, only to think you've got it ALL figured out, deliver the thing and immediately discover that they try to use it in a way you never anticipated.. or that they never try to make use of 50% of the things you spent a lot of (now wasted) time on.
Anyone with military experience knows the adage 'no battle plan survives contact with the enemy'. This is a known and expected thing, you try your best for a good plan, but in the end it is known you will almost always need to 'adapt and overcome'. But somehow we in the software development industry have gotten into our heads the notion that we can plan perfectly, and all we need to do for success is execute the plan exactly as specified. but seriously, now often does that work?
we're better to get something 'good enough' into the hands of the customer and then discover based on real usage and feedback what needs to be done to make it better.
July 24, 2009 at 9:02 am
A most interesting topic.
80% of features is totally acceptable. 80% of delivered content that works properly is totally unacceptable. If it is included in the deliverable, then it should be as close to 100% as possible.
Another way to look at it is...
1 out of 5 words mispelled,
1 out of 5 lines coded incorrectly
1 out of 5 functions work properly
Any of the above would make a product totaly ineffective. Failure to provide a product that works will result in loss of business, customers, and credibility. If the timing of the release cannot be adjusted, features that are not up to par should be removed and planned for future releases.
Joe
July 28, 2009 at 9:05 am
While I feel that we should always strive to get it right the first time, the requirements (user demands) tend to be dynamic by nature, which means that more often than not we are attempting to hit a moving target with our deliverables.
One way that I've found of improving the hit rate, is to design and code "function over form" on the first release. It's always better to deliver a functionally correct application than an application that has many bells and whistles and even more problems.
A former boss of mine had the mindset that the first deliverable could be considered a functional prototype or a throw away app that would be totally re-written for next release.
The bottom line is we must present a deliverable of acceptable quality in a timely manner if our employers expect to remain in business.
July 28, 2009 at 9:09 am
Mad Hacker (7/28/2009)
While I feel that we should always strive to get it right the first time, the requirements (user demands) tend to be dynamic by nature, which means that more often than not we are attempting to hit a moving target with our deliverables.One way that I've found of improving the hit rate, is to design and code "function over form" on the first release. It's always better to deliver a functionally correct application than an application that has many bells and whistles and even more problems.
A former boss of mine had the mindset that the first deliverable could be considered a functional prototype or a throw away app that would be totally re-written for next release.
The bottom line is we must present a deliverable of acceptable quality in a timely manner if our employers expect to remain in business.
Makes sense to me.
- 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
July 28, 2009 at 10:05 am
Tend to agree with that. Throw one away.
July 28, 2009 at 11:13 am
Yeah.... just not one you release to the customer. You only have one chance to make a first impression. Unless the customer is fully aware that you're going to turn out a "throw away" on the first delivery, you'll give your company one hell of a black eye that may also travel where you don't want it to simply by word of mouth.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2009 at 12:29 pm
Mad Hacker (7/28/2009)
While I feel that we should always strive to get it right the first time, the requirements (user demands) tend to be dynamic by nature, which means that more often than not we are attempting to hit a moving target with our deliverables.One way that I've found of improving the hit rate, is to design and code "function over form" on the first release. It's always better to deliver a functionally correct application than an application that has many bells and whistles and even more problems.
A former boss of mine had the mindset that the first deliverable could be considered a functional prototype or a throw away app that would be totally re-written for next release.
The bottom line is we must present a deliverable of acceptable quality in a timely manner if our employers expect to remain in business.
That approach is a lot easier to take if you are using TDD or BDD type methods where you have unit and integration tests that validate the program's function and behavior. That allows you the freedom to create 'ugly but correct' code, or as you put it 'functional prototype', on your first go-round. Then once you are sure that it's functioning properly, AND that your tests to that effect are good, you can commence a re-factoring of the internal code with the security of knowing you'll find out as soon as you run the tests (which you should do frequently) if you've broken anything in the process of your re-write.
Also makes it a lot easier for someone else, or even yourself to modify that code months/years from now, and have a in-code reference to 'what was this supposed to do?' and assurance that you'll know if your modifications have broken anything.
I'd refer you to the recent articles on TDD (Test Driven Development) that have appeared here over the last few months if I had the links handy..
Viewing 15 posts - 31 through 45 (of 53 total)
You must be logged in to reply to this topic. Login to reply