The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

I waste way too much time on design...

I'm working on my own project which I would like to release but I just can't finnish it because of constant planning, refactoring and basically trying to work out the best design which will cover 100% of possible future problems like deployment, portability, backwards-compatibility etc...

This costs me a lot of time and it seems like I waste 80% of my time on thinking about design and then spend only 20% on real work.

Please help me to get real.
anon for this one
Tuesday, January 09, 2007
Visualize the end product as it is, not as you think it can be improved.

I had to fire someone for this analysis paralysis.  He was a non-finisher, never moved a damn thing into production.  Refactor, redesign, rewrite, etc.
D. Trump
Tuesday, January 09, 2007
Design it for now, acknowledge that things can be improved, and move on.  Making it "perfect" now without real-world feedback is worthless.  Once you have customers and a vision of what they want, then you can re-evaluate priorities.

As long as you log or write down the potential issues somewhere, you don't have to get too deep into them now.
KC Send private email
Tuesday, January 09, 2007
It really depends on what you mean by "design" but the CMMI methodology implies that a ratio of 10:1 is normal on large scale projects, that is 10 hours of requirements gathering, scheduling, design reviews, approvals etc etc for every one hour of actual coding.

CMMI rightfully earns its fair share of criticism since it doesn't really take into account the type of project you're working on, but basically, 80% of your time spent on pre-coding activities.

However, you should keep in mind that project schedules do specify when to stop designing and when to move on. For example, if you've given yourself a year to release your product, then you have essentially 9.6 months to design your product and figure out all the details. Anything that you can't decide by then, you save for version 2.0.

Also, keep in mind that very few people will actually look at your source code or documentation (unless it's open sourced). Refactoring the code benefits you, but may contribute nothing towards getting it out the door.  In my example, you may have reserved two months for coding.  If you're not "done" in two months, just throw it out there as is and move on.
Tuesday, January 09, 2007
"...but basically, 80% of your time spent on pre-coding activities."

That should be "...pre-coding activities is normal."
Tuesday, January 09, 2007
I've found that setting up a strict version numbering system helps this psychological block. the major version number only changes when an existing API breaks, the minor revision number changes whenever a new API is added, and the build number changes on each bug-fix. This lets me introduce a 1.0 product, perform bug fixes and expansions on that product, while still working on a better API for the 2.0 product.

Another factor that helps me get a version out the door is knowing that it's not possible to design to meet 100% of all cases, and even if it were possible, you'd need a LOT of outside input (from your users) in order to even approach it. Releasing a product, however flawed, generates feedback that you can use when working on the next version. If all you are doing is developing from your own assumptions, then all your work may wind up being for naught, but when you develop based on external feedback, you know that the results will be useful to at least the people that gave you the feedback.
Jeffrey Dutky Send private email
Tuesday, January 09, 2007
+ 1 KC & the Donald.

Every software product can always be improved upon. And for every release \ version there will inevitably be features that get cut simply because there isn't enough time to get them done before the deadline.

You might want to review Joel's article on picking a ship date for some inspiration & steps you can take to get your product out the door on time.

You're never going to be able to fully anticipate how clients will use & want to use your product. You're better off coming up with a feature set you want in the initial release, code and test the heck out of it, release it, and get some solid feedback from clients on what they like, don't like, would find useful, etc.

Good luck, and get coding!
Tuesday, January 09, 2007
When I get into these situations, it's usually because I'm trying to invent the "perfect" design.  What I've found helpful is to decide to implement a known crappy design.  So if I'm storing data, just store it in a text file; if I have a collection of properties, just use string key/value pairs; whatever.

Any solution can have problems, but they might be problems you'll never actually have to deal with anyway.  With refactoring, you can always come back and put in a better design later; but that way you'll know you actually _need_ the better design.

(I'm not arguing for sloppy coding, by the way; even your crappy design should have good code without duplication.)
Kyralessa Send private email
Tuesday, January 09, 2007
Don't just design. Instead design, implement, test and demo in small iterations, one feature of a time.
anon for this
Tuesday, January 09, 2007
Make a list of your highest priority features. Draw a line under the ones you think you need to attract a small number of loyal customers who really need your key differentiating features. Implement each feature until it works but is not perfect. When they are all done deploy. Continually keep implementing and releasing new features in priority order.

This still leaves room for judgment, but you always have that room. Prioritize, do it good enough, and deploy. Don't over think because it usually doesn't matter. Where it does matter you probably can't predict and will screw up the first few times anyway.
son of parnas
Tuesday, January 09, 2007
All good advise here....
I would add my two cents: Try to work vertically.

That is: Design one (small) independent feature of your program, one that does not depend in any way on other features. Surely there is less design+code work on such a feat.
Then code it until it is code complete. Do the architecture and  design. Code (and unit test) the infrastructure, business logic and GUI.  Test it all. At this level, you will flush out most of your architecture and design problems.

After that, you can design more vertical features and add them to your program easily.

Best regards,
Ari Telias Send private email
Tuesday, January 09, 2007
A deadline is a very useful thing to focus your mind and force you to make hard decisions -- tradeoffs of features versus schedule, etc. Remember: no company has ever shipped a perfect product. And no one is going to start now. I'd bet lunch money (and more if I had it) that the Apple iPod has some bugs in it. It's a fabulous product, but there is no way the software is perfect. But it sure is good enough. (Someone once said "Perfection is the enemy of good enough.") Not to be TOO self promoting, I wrote a review of Steve Squyres' book ROVING MARS, which is about the development and deployment of the Mars rovers:

but you'll be better off skipping the review and reading the book! It is a GREAT book on product development. Talk about a hard deadline: they had a fixed launch window that would not reoccur for 18 years! They had to make very hard decisions on features versus schedule. I really got the feel for the _drama_ of product development.
John Sloan Send private email
Wednesday, January 10, 2007
>the best design which will cover 100% of possible future problems like deployment, portability, backwards-compatibility etc...

If it were possible to cover 100% of possible future problems, why do we have continuing education?  Why did any band ever release more than one album, or any author write more than one book?  Why does anyone have more than one child, or date more than one person, or....  You get the point.  Your premise is deeply flawed.  It's not possible.

>>This costs me a lot of time and it seems like I waste 80% of my time on thinking about design and then spend only 20% on real work.

No: You are spending 80% of your time daydreaming, or perhaps worrying, or trying to foretell the future.  If you were really designing, you'd already have something to code from.  Design understands that not all situations can be provided for.  It's way easier to try to forestall all problems.  You never have to worry about the biggest one--will your software actually sell? 

>>Please help me to get real.

Do you want to fish, or cut bait?  If you're cutting bait, open a bait shop. 

Your call.
Ideophoric Send private email
Wednesday, January 10, 2007
Go read "Getting Real" by the folks at 37Signals -
Fat Bobby Send private email
Thursday, January 11, 2007
Often, the underlying reason for this type of analysis paralysis is simply the emotion of fear.  The suggestions for improving your development process are good, but do not address this issue.  Google "fear of completion".  You may want to consult with a therapist, also a hypnotist may be able to assist with neutralizing this fear directly in your subconscious.  If this (common) problem is affecting your career it may be worth looking into.  Good luck
Friday, January 12, 2007
All excellent replies IMO.

My contribution:

Re-read what Kyralessa said, specifically about just using any kind of design for each feature.. even a 'known crappy one'.

Then you code to the INTERFACE.  Those parts that you coded, that you don't like so much, you can improve them *later* without breaking anything, when you have the time and the product is out the door.

check out Head First OOAD
Friday, January 12, 2007
Software design can never be more important. I've met developers who jump straight into coding (perhaps due to deadline pressures) without proper design. In the end, if a software was designed well, it will significantly make coding much more easier and the software will be a much better quality product! fully satisfied. Show it to as many people as possible. THEN code...
Ezani Send private email
Tuesday, January 16, 2007
Sounds like you are doing requirements, not design, and that you are trying to determine 100% of the requirements in one-big-step.  This is also known as "big design up front", or classic waterfall methodology.

The cure is to decompose the product/project into smaller releases, either time-boxed or feature-boxed, prioritized by risks and benefit. 

Your old project plan looked like:
  - 100% Requirements -> Analyse -> Design -> Build -> Release 1.0

Yor new plan looks like:
  - Prioritize functionality by risks and benefits
  - Define Releases
  - Top 25% Reqs -> Analysis -> Design -> Build -> Release 0.1
  - Next 25% Reqs -> Analysis -> Design -> Build -> Release 0.2
  - Next 25% Reqs -> Analysis -> Design -> Build -> Release 0.3
  - Last 25% Reqs -> Analysis -> Design -> Build -> Release 1.0
G Send private email
Thursday, January 18, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz