July 15, 2009 at 12:26 am
Comments posted to this topic are about the item Over-Engineering
July 15, 2009 at 1:08 am
We can get it right the first time if we know it right the first time and is invariant. Requirements for applications have had the nasty habit of not being defined clearly to the last dot, or if they have been by the time the software is built changes have crept in.
July 15, 2009 at 2:29 am
I just have to disagree. Or well, it depends on the product and what it's about. But if it's something important then it should work and not some 20% failure rate. Why do I think it should be finished before shipping? Well,do you buy a Microsoft operating system before sp1 is out or do you buy it after sp1 is out?
July 15, 2009 at 2:51 am
so you might as well ship something that's 80% right and then plan on fixing it right away
I have to disagree with that notion.
If I buy some software, I want it to work 100%. I may have bought it specifically because of the 20% that doesn't work, in which case it's of 0% use to me. Would you buy a car that was 80% right... one that failed to get you to your destination 20% of the time?
The "fixing it right away" never happens, because resources get moved on to developing the next version.
July 15, 2009 at 3:02 am
Sorry, Steve, but I also have to disagree. I have had the misfortune to be a DBA on the receiving end of database solutions that have been shipped "80% right" or less. It is unbelievably frustrating to be having to spend all your time firefighting inefficient DB apps, having to kill spid's that are blocking, trying to determine why database calls are freezing out systems, and I could go on and on.
While I agree that some solutions can be over-engineered, that should simply be a case of managing customer expectations - give them what they want one small bit at a time and build on it bit by bit, getting each small bit correct. Ultimately you reach a point of diminshing returns, when the cost to add the extra widget is greater than the r.o.i. - then you know when to stop.
July 15, 2009 at 3:58 am
I think some of you are missing the point - or perhaps I am 🙂
When I read Steve's article I interpreted it as 80% functionality rather than 20% of it not working. When I write software I often fall into the trap of trying to think of every possible way that someone will want to use the product and then try and design the software to be flexible enough to do all these things. Although a laudable aim, it takes me far too long to add the functionality and then despite its flexibility I usually have still failed to envisage a particular use.
What I try to discipline myself to do, is write the bare minimum functionality (i.e the 80%) and then refactor and add the additional functionality as it is required. This way I find I can have something working more quickly and the additional features are those that the clients require rather than those I have dreamt up.
July 15, 2009 at 4:55 am
Yeah, I don't think Steve is advocating releasing software that is 20% broken. I think it's more to do with releasing software that works to a point, rather than always trying to go beyond that point. That is to say, don't give in to scope-creep; Release something and take on board feedback to amend where appropriate.
Often we give people too much choice when we over-engineer software. Sometimes I think the designers should just pick a way of doing something and let us have it.
July 15, 2009 at 5:02 am
Zac Mace (7/15/2009)
I think some of you are missing the point - or perhaps I am 🙂
Steve's article is obviously open to interpretation, but
ship something that's 80% right and then plan on fixing it right away
If it wasn't broken, it wouldn't need fixing 😉
July 15, 2009 at 5:59 am
Perhaps one should consider the situation before deciding the release software that is 80% right. I don't think that NASA astronauts would be real confident in flying the shuttle knowing that there is a 20% chance any one software function will fail on invocation.
Or consider something more personal. How confident would you be in undergoing a medical test or procedure where the software involved STARTS with a potential 1-in-5 failure rate? I'd think that if some of those same gang of Vista engineers had the tables turned on them in this way they would have had a very different attitude.
That being said, if all you can get out of the customer is an 80% plan, then fine. 20% won't work BECAUSE IT ISN'T THERE. But don't slack off on the other 80%. Surely we can develop software that at implementation time has a better than 1-in-5 chance of working.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
July 15, 2009 at 6:08 am
My boss used to complain that I over engineered some of the custom data tools that clients use in conjunction with our software. But over time the praises and lack of complaints from clients has led to less rework and higher job satisfaction.
July 15, 2009 at 6:24 am
A very timely editorial Steve...
A few weeks ago I was sitting on my deck with a few friends, two of whom, like me, began their careers as developers. We were talking about all the paradigms that have simply disappeared or become meaningless in software development since the advent of the web and the .NET craze.
In our day long ago, working then in 3GL's, we were excited about the 4GL systems that were coming out and would eventually lead us into a huge period where the buzz word was RAD (Rapid Application Development). Those things just faded and disappeared and I don't doubt would seem like fossils to todays young developers. I remember doing a project with one of my employers, a world-wide facilities management provider where, in 42 days we delivered a large, fully working management system. Today, especially in .NET, I would guess the same project would take at least two years.
We all came to agreement that the "Golden Days" of software development are indeed gone forever. In our day there were probably 20 or 30 development systems and "languages", where today, you dance to .NET or Java, and just about nothing else. Developers today are required to march in lock-step to a set of ideas, concept, and principles - there is "one way" to do something, and not the kind of leeway we knew coming up.
In my view, Over-Engineering is now the norm. How we got that way is really due to market control and dominance - today's younger developers have far fewer choices than we had when it was our time. For me, this is a sad fact because its killed a kind of creativity we wont see again. Worse, no one questions that anymore, they just accept it and march in lock-step, and this has killed a certain creativity and shifted it to the very thing we once thought we would never accept.
Everyone dancing to the same Over-Engineering music. But worse, never questioning why. Good software was once written and produced quickly, and then refined as time went on. In those days anyone could write and market a system, and some became millionaires. Those days are gone forever, lost in the new "standard" of Over Engineering.
July 15, 2009 at 7:00 am
It's unfortunate I believe, but over-engineering is the norm in today's software development. Many people probably remember the term spaghetti code, referring to poorly structured code with little or poorly designed logic flow controls, well the systems I've worked with over the past 4 years or so have so many application layers that they've earned a new name, lasagna code. Lasagna code systems are easy to identify, they have so many layers that whenever a new feature needs to be added to existing functionality it takes 4 times as long because you have to add it to all the layers. Troubleshooting is also 4 times as difficult, and maintenance becomes a nightmare.:hehe:
July 15, 2009 at 7:29 am
blandry (7/15/2009)
In my view, Over-Engineering is now the norm. How we got that way is really due to market control and dominance - today's younger developers have far fewer choices than we had when it was our time. For me, this is a sad fact because its killed a kind of creativity we wont see again. Worse, no one questions that anymore, they just accept it and march in lock-step, and this has killed a certain creativity and shifted it to the very thing we once thought we would never accept.
I wonder about that sentiment because I've heard it from other people before. In my view creativity isn't gone, there are still plenty of languages to learn. .NET is not a language but a framework, C#, VB, C++, F#, Python, COBOL, and many more languages can all target it. There are other languages I don't use so much, like Ruby, that are popular too. Different languages encourage different design patterns, I find it very fun and rewarding, and yes creative. 🙂
It's just the nature of things to evolve. The challenges of before have been solved to a certain degree and consequently they enable us to tackle bigger challenges. Instead of re-writing code ad infinitum libraries were created. Instead of repeating common tasks libraries morphed into frameworks, mini OSs in a way. Just like there are many languages and libraries there are many frameworks. That's proof to me creativity is alive and well.
Interesting thread. And yeah, I don't agree with your assertion, Steve, that code should be released 80% right. Limiting the scope of a particular program version and completing everything within that is better I think. If new ideas come about while coding, defer them to the next version so you can actually ship something, that works.
July 15, 2009 at 7:36 am
I tend to agree with Steve - get 80% of the functionality right. Then identify and trap the scenarios that you haven't accommodated so that you aren't creating erroneous data. We spend so much time trying to cover that remaining 20% that we lose a lot of business value in the process.
Chances are the spec's are going to change after the 1.0 release anyway...
July 15, 2009 at 7:50 am
The most important thing is to ship a product that is working 100% correct. If not all functionality is available, swah, it can be added later. But it is very frustrating when (part of the) the product is not working!
Viewing 15 posts - 1 through 15 (of 49 total)
You must be logged in to reply to this topic. Login to reply