Over-Engineering
-
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
-
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 -
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.
-
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
-
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.
-
Because this is an old post I'm going to skip over Agile development and Dev-Ops and guess that we all use SQL Server of some kind. Picking on Microsoft SQL Server 2019 (its what I use) it's on the 29th Cumulative Update i.e. 29 cases of bug fixes and additional features. Maybe not in the proportions Steve mentioned but this is a case of getting a product on sale then fixing what's broken and adding new features to it. I'm sure lots of us can find other cases like this too.
-
WOW! An article from 2009! I think that may have been before I joined SSC.
I work in state government. We don't try to make all software we produce 100% complete, but we do tend to get it asymptotically close to 100% complete. Consequently, all software projects take years to complete. So long so that normally the users have lost interest and moved on. Add to that UI and UX issues so egregious that the users will not use the software, once delivered. It has been at least 6 years since I've been a part of a software project that we delivered to the users. It's very discouraging. At my old job almost every project we started, we delivered, in less time. At this job almost none of the projects I've worked on are in use today. Getting back to what Steve wrote 15 years ago, I don't know if trying to have a complete software solution is a part of the reason for so many failures or not, but it certainly did contribute to it.
Kindest Regards, Rod Connect with me on LinkedIn.
-
This reminds me of a situation I have related earlier on here regarding being overly cautious in getting things implemented versus getting things perfect. Last shop I worked in was doing a very large dealer network application using our large department assets of about 40 people and even some help from Microsoft - spending millions of dollars over several years. I was given a task of debugging a stored procedure for a report that was producing 'questionable' data. It was one of a series of about ten such reports that were all based on very similar sprocs which had all been created by a VB developer on the project - and that all contained a common error.
So I fixed the error in all of the procedures, tested, verified and released them to the QA (Quality Assurance) group responsible for testing and releasing changes. This was in the early days of the 2000's. When I retired on 4-30-2010, the fixes had never been released. Several years after that my old boss related to me that the bug fixes had never been released, and the whole system had been retired and replaced.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) ) - skeleton567 wrote:
Several years after that my old boss related to me that the bug fixes had never been released, and the whole system had been retired and replaced.
Ya just gotta love those all those initial "perfect is the enemy of done" releases, right? Seems like they never actually hit the proper "good enough spot" because "good enough" usually isn't.
Perhaps I'm missing something in all of that but, to me, not working correctly will never be "good enough". And if the 20% isn't working, then don't ship it because someone is going to notice and it WILL be on the customer end of things and your company WILL be on the "they suck" end of the stick.
Must have been more than just those things that you fixed that were wrong enough to cancel the project.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Viewing 9 posts - 46 through 53 (of 53 total)
You must be logged in to reply to this topic. Login to reply