A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
The question is between "pure philosophical" and "somewhat pragmatic":
- Where is the point, where you stop asking WHY?
- When simple design does not work?
- How often complexity of design decisions is reflected on implementation and maintainability.
Let's say you design an enterprise e-commerce application. What is the most granular design decision being documented or discussed? Can you (or your application architect/system designer) always answer why specific technical decision was made? And by "answer" I mean a professional explanation involving statment of business goal(s) and a clear demonstration (a reasoning, sometimes prototype, sometimes references to other prooven solutions), that choosen design achieves goal(s) with optimal development/maintenance effort.
I have a feeling (nothing measurable, just an experience), that when developer has poor understanding of the reason for a specific design decision, the chances for bugs, increased maintenance and development time are very good. To make things worse, it is only this many "uncertainty points" a good developer can have with design, before it either becomes critical to his/her performance or turns developer into a mindless coder, that blindly follows design specifications.
I'd like to get your opinion on how precise design can or should be. Is it at all possible to show corelation between how well design decision was justified and conveyed to developers, and how it affects implementation performance, maintenance efforts and amount of bugs?
Monday, May 23, 2005
I think it is very important to ask these questions.
- if you are a contract programmer who will only be in the industry for this one project, there won't be much time for you to become very knowledgeable in the industry and it is essential that the design spec is absolutely clear.
If you are working for a company where you will be in the industry for your career, you should be asking questions to help your career. Those writing the spec may assume a level of knowledge because you are an "insider."
In either case, however, it is up to you to ask questions if you are not clear on intent, otherwise your code will be useless.
A product is said to reach the perfect state when there is nothing left to remove without sacrificing the features.
Based on this idea, it's usually a matter of experience to simplify complex systems and designs.
So, I would recommend you to start as simple as possible, then continously add features in minor releases.
Overengineering is a very common mistake we all make.
Monday, May 23, 2005
> What is the most granular design decision being documented or discussed?
It depends on your experience and the exprience of your team. If you have experience in a domain the see as far as you can see. Personally there has only ever been a few occasions where I go into detailed class diagrams. I would stay a level above that and let it evolve.
I would also make sure that key requirements are being met. Performance, memory usage, compatibility, load, fail over, that sort of thing. You have to make sure those are taken care of.
But don't try and work at to low a level. Don't worry what a class is called or a method is called. It slows things down and doesn't add value because of all the change that will happen.
I would recomend using Scrum so you limit your risk to small iterations.
son of parnas
Tuesday, May 24, 2005
If you get the chance, pick up Eric Evans' Domain Driven Design. There are specific design patterns in there to manage that kind of complexity in code, but what's much more rewarding is the second half of the book. He gives you loads of practical advice on just the sort of communication problems and compromises you're talking about.
There's a Yahoo Group that's quite active:
They'd probably disagree with son of parnas: low-level design decisions matter, insofar as they ensure your team (and the many teams that will follow them) are speaking the same language.
Sunday, May 29, 2005
Caveat: I am an embedded developer. I like to draw data-flow diagrams. I use these conventions:
1. I draw tasks (threads) as a bubble
2. I draw sets of API functions as a rectangle. These are functions which will become a part of whatever thread calls them.
3. I draw mutexes as a little flag. Resources that are accessed from multiple tasks (or from re-entrant API functions) need to be mutex-protected.
4. I draw queues as pairs of parallel lines, and arrows to indicate who is putting data into queues, and who is taking the data out. Doing so may reveal bottlenecks, or the need for additional mutexes.
5. I annotate the drawing to indicate how the tasks will block, who is polled, and who is interrupt-driven.
6. I tack the drawing up on the wall so I can look up at it whenever I get lost in the woods.
7. I get a technician to redraw the thing in visio because by the time I'm done with it, it's full of erasures & modifications. PS: I immediately update the drawing when, in the course of implementation, I realize I've made a mistake.
Tuesday, May 31, 2005
> low-level design decisions matter, insofar as they
> ensure your team (and the many teams that will
> follow them) are speaking the same language
I don't think they matter enough to spend time doing a detailed design on. Much like we don't talk about steering right or left when we talk about how to get from point A to B.
son of parnas
Friday, June 03, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz