meenakshi sundar wrote:On theory, Design drives implementation, but in the real world I have seen on many occasions a good design implemented very badly
What would be an example of a "good" design that is implemented very badly?
I think this is what gets many developers in trouble, when they consider "design" and "implementation" as separate things. Code is the embodiment of design, so when you code (i.e. write the "implementation" as you call it) you are actually creating a detailed design.
Are you perhaps referring to "high-level" conceptual design in the form of a picture/diagram or in the form of plain text description (non-executable) vs. low-level design in the form of source code?
On theory, Design drives implementation, but in the real world I have seen on many occasions a good design implemented very badly
How do we manage to narrow the gap between A good design vs bad implementation?
Junilu makes a good point on this.
Are you referring to the act of first designing, then putting an implementation together that doesn't satisfy or abide by the design.
In the past, and I know one very specific example in my career, where we built a design for our system, then moved into the "implementation phase" when we almost immediately realized that the design wasn't going to work. So, we had to change our implementation, which made it diverge from the design.
What would constitute a "bad implementation?"
The way that I try to keep from having a divergent value in my design vs my implementation is to minimize the time and size between making the design and making the implementation. This is often part of the idea of iterative- or incremental design. In general, pick a small set of behaviours that are needed and implement a design to satisfy those. Then, determine another behaviour and see if your implementation will satisfy that. If not, then see what changes to your design are needed. make those changes, implement them, then verify that the original behaviours are still satisfied (a nice automated regression test suite is good for this). Then, pick the next small behaviour and design/implement a solution for that. Then just keep doing this.
During this process, it may become clear that the path you are on is a dead-end and won't satisfy upcoming behaviours. At this point, you have A LOT of knowledge about what the design needs to support, a lot of knowledge about how to build a system that will satisfy them. At this point, you can either make changes to the existing design or build a new design that doesn't make the same mistakes that led you to the dead-end.
There is a saying "you are never more ignorant than you are right now," so taking small steps in building and implementing a design helps fill in the gaps in knowledge.
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database