July 29, 2009 at 7:11 am
Jeff Moden (7/28/2009)
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.
I've actually used a lot of freeware/shareware/FOSS/etc. software where the first public iteration was fully functional and did everything it was supposed to, but had a clunky looking interface or even just a command-line interface.
It really depends on what customer you're releasing it to, and what expectations you set.
But, for the most part, you're right about first impressions, et al.
- 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 29, 2009 at 8:03 am
I still think that there is some misunderstanding about Steve's intent in the editorial. I think his premise is that many times we, as developers, are continually thinking about some feature the users may want so that we never get out the features that they have to have. Thus we need to deleiver the major functionality and then get the rest of the features out in service packs or upgrades.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
July 29, 2009 at 8:34 am
Jack has it pretty close. Developers also focus or worry about things that may or may not be what is needed by the client. That's natural, we have a different perspective. And it's why a good relationship, even in simple CRUD applications, goes a long way with the client. Especially over time. Turnover in your staff also hurts application development.
The thing we often do, is that we highly engineer code, thinking that we don't want performance to suffer, or that we want to handle all loads. sometimes that's at the request of the client. And while I agree with Jeff's preaching about writing good code to start with, we don't, or shouldn't, write code slower to make sure we've been as efficient as possible. It isn't always needed.
It is needed at times, but I've seen way more apps that were built slower than needed, and never were heavily used than apps that were poorly built and had performance issues. We hear about the performance issues, but we don't hear about the applications that were built and never got used.
June 2, 2015 at 8:10 am
Joining in this discussion very late because the article was referenced in something else I read recently.
I reckon that in software development under-engineering is far more common than over-engineering, and causes far more cost over-runs and far more lost customers.
And I have to say that a total failure of the requirement determination process where people sit around arguing about whether the first release of their horse should have three humps or only two and whether the first release of a pig should be fitted with wings or with a lifting rotor is not over-engineering at all, although a lot of people who have commented here (and apparently Steve himself, judging from his responses) call it that. It is in fact under-management and under-engineering operating hand in hand.
Similarly, when a requirement is fulfilled and the result never used that isn't over-engineering - it's another utter failure in requirement determination.
Tom
June 3, 2015 at 12:34 am
Who uses 100% of an application?? If the 20% that doesnt work is the 20% that I dont use then I personally have a 100% working application. If the 1% of the application I need to work is broken then the it may not matter about the rest working, the application is broken.
Anyway it tends not to be clear cut anyway. Bits may work but need improvements. Other parts may not performance well but technically work. And other parts may not work but there is a workaround. Its where it is on the scale.
Viewing 5 posts - 46 through 49 (of 49 total)
You must be logged in to reply to this topic. Login to reply