functionality vs. quality

It seems to me that nearly all successful software is developed using one of the following philosophies, but hardly ever a combination of the two:

• Extensive Functionality, often at the expense of performance quality or added bugs. Software is written with a vast array of functionality and maintenance involves fixing malfunctions and other bugs.
• Accurate Performance, normally at the expense of breadth of functionality. Software is written with very little functionality, but a lot of attention is focused on those parts, making them function very well or accurately. Maintenance is normally for adding functionality, but those features added are contemplated carefully.

I'm guilty of both strategies and sometimes switch from one to the other after a certain point. Off hand, it seems that software with numerous features win the audience when placed side-by-side with others that test features extensively before actually adding them.

As a user, I personally prefer fewer features with better performance, so long as those features allow me to do everything I need to do. I also don't like encountering software that's so extensive that a lot of it isn't documented, but as a developer I like writing documentation about as much as washing the dishes.

When writing software, I'm always tempted to write in as much functionality as I can think of to start with (and I generally do,) but I don't like having programs where things don't work.

PS I developed my list library with a ridiculous amount of functionality and have since been debugging it, whereas I wrote my data protection library with very little functionality and have been adding to it since.

I don't view this as an either/or situation. I always try to fully meet the design specs while writing zero defect code. I suppose that you might have to make this type of choice if management imposed an unrealistic deadline on you. In that case you should kick the choice back to the person setting the deadline.

Incidently, this is one advantage that open source developers have over proprietary developers. Open source developers in general don't impose deadlines on themselves, much less unrealistic deadlines. Therefore open source projects don't get screwed up by trying to meet unrealistic deadlines.

-------------------
Steve Stites

I agree with you entirely, but even in the open source world there is a general philosophy of "release soon/often". I'm often torn between releasing an update when it passes the visual reviews and basic run tests vs. waiting until it's fully tested. I find myself doing both, but I'd much rather wait and be almost entirely sure. Something I'm also torn between is adding interesting functionality vs. constraining features to a concisely tied together interface.

A specific example that always comes to mind is KDE with all of its features, some of which fail miserably, and XFCE with very basic functionality which never seems to fail. This is just my personal experience and isn't based on research, but the example illustrates the basic idea.

My question pertains to what you'd prefer when you are in control since professional development is obviously subject to customer service politics.
ta0kira

I picks a combination of the two, all the functions needed for it to be usefull to a large number of people, but high quality code so it is reliable.

@jailbait: the question didn't say anything about the specs. What I've seen, increasingly, in my 30 years doing this is that too many people meet specs, but add "extras" that they "might need later" or that the customer "forgot" to ask for or "because we might be able to use this for another client, and we want to start from a single code base".... and so on.

I've adopted three basic rules that have allowed me to keep what little hair I have left:
1) No code gets written without a failing test case.
2) Said test case is tagged with the spec detail (requirement number) it is tied to. No req, no test case, no code.
3) Client signs each update to original spec, explicitly accepting responsibility for schedule/budget impact as estimated.

First-time clients are a little confused by being so deeply involved -- until they understand that this is the best way we've found to give them exactly and only what they've asked us for, with as few major gotchas as possible. They're not surprised by any fancy features they didn't ask for (and didn't expect to pay for); they're also not surprised by any sharp edges or holes in the pavement.

Back in the day, Lockheed-Martin called it "rapid quality iterative development". The principles got sucked into "extreme programming", and now the latest buzzword is "test-driven development." I have never worked in a shop that did things this way that had problems with either overtime or delivery. I have very rarely seen shops that didn't do this where people didn't run themselves into the ground. Doing that once or twice when you're young and seemingly indestructible can be fun if you pull it off in the end. As you get farther along in life, you realize that you really would prefer to have a life.

If conceived in an object orientated fashion and built through libraries then each part can be checked for accuracy and then strung together for extra functionality. That said however, I do tend to put in reserved's for later development concept's, however at some point you gotta make a start. Also the wisened word's of 'jdickey' keep projects on time, in budget and with a higher profit margin.

@brazilnut,

I'm all for keeping track of ideas for future additions to projects; that's one of the main things I use a wiki for. But just to re-emphasize the point: code gets written in response to a failing test case, which is written in response to some form of design or architecture documentation. Nothing says all of the above can't be "living documents"; just that the customer only pays for the solution to *his* problem with appropriate technical and financial paper trails attached. If you've got 100% code coverage in your tests, and 100% tie-in of test cases (and hence, code) to requirements that the customer can understand, then you've got zero customer surprises -- and, generally, three hecks of a lot less work.

If anybody has a better way of doing things, I'm all for it. If you're doing a project just for your own amusement and edification, of course, the preceding doesn't apply so much - but I've found that I tend to use the same basic process anyway, just so I'm sure I understand what's going on. Of course, if you're one of those uebermenschen whose code never has defects and who always goes home at the end of the business day, you can ignore the whole thread. :-)

That's funny you mention having a life and not working overtime, jdickey. Programming has been a parasitic hobby of mine for well over a decade, so I finally decided that if I go to school for it and do something related then I won't feel the need to use my own time for it. We'll see in a few years, I guess. Maybe one day I'll swear off coding forever! One can only hope. Until then, I'll keep your strategy in mind.
ta0kira

Yes, being self taught it's always just been a passion for me. Also starting with writing plugin's for 3dsmax and autocad db scripts, my approach was always focused and very job specific, yet maybe a little less hardcore when it came to the pragmatic higher ed philosophies of computing, I was just into architecture, and let's face it oop's is just the Bauhaus movement but for computing math...

Sounds a lot like what I've heard called software evolution vs. software revolution. Personally, I'm of the camp that software should be as correct as possible before being horribly wide-ranging; who needs features that don't work right? It seems to my mind best to work on getting one piece of functionality correct before moving on to others, for a few reasons. One, it narrows the scope of the current work. Two, once you can put your faith in some chunk of code, you can depend on it to act faithfully as a basis for later work. (This also decreases the scope of the work, as later debugging doesn't have to thoroughly re-evaluate the part of the code you consider already "correct".) Three, it's more the Unix way, which has a historical precedent for working pretty well.