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.

Implementation Driven Design

I wrote the following article and submitted it to Kuro5hin.org and it was rejected almost immediately. I am wondering if JoS readers see merit to the approach:

Implementation Driven Design is a software development methodology with the same goals as many other methodologies such as modular programming and object-oriented programming:

- improving maintainability
- decreasing defect rates
- increasing programmer productivity

As is a common in other methodologies, this is accomplished by reducing complexity through decreasing code coupling and increasing the usage of abstraction. Implementation Driven Design can be described as the following process:

1) given a problem description, express it as simply as possible in terms of functions and classes which may or may not exist
2) for any function or class that does not yet exist, express it as simply and generically as possible, in terms of functions and classes which may or may not exist. Repeat this step over and over again, until all functions and data types have implementations.

While designing classes and functions using IDD the following guidelines should be adhered to:

- classes and functions should be kept as small and generic as possible
- classes and functions should be designed with reuse in mind but without superfluous functionality
reuse of existing classes and functions should be done as much as possible
- code should be easily verifiable for correctness by others

The challenge of IDD is to be as generic and reusable as possible but without providing unneccessary details. For instance it may be tempting to include all manner of useful functions within a class, but this can lead to unused implementations or in the language of extreme programming practitioners, when YAGNI's (You Aren't Going to Need It).

What sets IDD apart from typical practice, is a heavy emphasis on small and reusable components, to a degree which is more than what most programmers are comfortable with at first.

IDD is based on the following observations:

- reactoring functions and types during design is cheaper (in terms of programmer time) than during implementation
- simpler functions and types are more likely to be reused
- as complexity of functions and types increases, defect rates increase exponentially

It is rare to have classes or functions which are too small, as long as they have clear and well-defined roles.

IDD is related to extreme programming in that the designing principles are quite similar: maintain simplicity and refactor frequently. Extreme programming includes numerous other guidelines and rules which govern all aspects of software development including customer interactions. Apart from that the other rules of extreme programming may, or may not, be applied at the discretion of the developer.

IDD in of itself was developed originally as a solo agile development technique which adapts to frequent changing specifications. This contrasts also with extreme programming which is intended as a team based software development approach. Part of the philosophy of IDD is that specification can and usually do change quickly and frequently, despite the best efforts to make them commit to a specification. Implementation Driven Design addresses the need for flexibility by promoting extremely compartmentalized code.

No software development methodology is complete in of itself, but hopefully IDD can make a useful addition to a programmer's toolchest.
Christopher Diggins Send private email
Monday, November 22, 2004
 
 
I think that testing should be explicitly mentioned in there somewhere.  There should be a way of objectively verifying that the code works, and design alone does not do that.  A really elegant design can easily have a faulty implementation.  You can do it with unit testing, or some other method, but it should be in there.

How long or short should an iteration cycle be?

How do you know if a chunk of code is reusable at the first iteration of an isolated project?

Where is the line between a long chunk of code and a short one?
Aaron F Stanton Send private email
Monday, November 22, 2004
 
 
I refrained from mentioning testing, because that is a contentious topic and depends very much on the size and complexity of a project. Testing stringency varies significantly between different problem domains from NASA software to a one-off perl script.

"How long or short should an iteration cycle be?"

As short as possible.

"How do you know if a chunk of code is reusable at the first iteration of an isolated project?"

What do you mean by isolated project?

"Where is the line between a long chunk of code and a short one?"

It's hard to define quantatively, but I would say as small as possible such that it still has a single easily defined role, and that further factoring would no longer reduce complexity.

Thanks for your comments Aaron.
Christopher Diggins Send private email
Monday, November 22, 2004
 
 
Glad to help.

By "isolated project" I mean that in a typical shop one would have several sets of apps one works on, some clearly related, some not so much.  If one has only one app, it's certainly isolated.  Also, you could have an app that is not really used in conjunction with any other app developed there.
Aaron F Stanton Send private email
Monday, November 22, 2004
 
 
"How do you know if a chunk of code is reusable at the first iteration of an isolated project?"

I have found that reuse centered design extremely effective even if nothing gets reused ever. The iteration phase that I refer to is during design so it is exceedingly rapid. I hope I am addressing well the points that you bring up?
Christopher Diggins Send private email
Monday, November 22, 2004
 
 
So far so good!
Aaron F Stanton Send private email
Monday, November 22, 2004
 
 
Your article needs a lot more work before people can appreciate the value of your ideas correctly.

As a general comment, a lot of the content has no context and because of that it become ambiguous. Plus you make a lot of non-committing statements that lead to contradictory interpretations.

1) "Implementation Driven Design is a software development methodology..." Design is only a small part of the development process. Examples of development processes are: RUP, XP, SCRUM...

2) " ... this is accomplished by reducing complexity through decreasing code coupling and increasing the usage of abstraction" A system should not be too abstract nor too concrete. Your statement does not hint on how abstract or how concrete. For more info, read on Martin Metric. BTW, introducing a layer of abstraction increases code complexity and may decrease component coupling only when applied correctly.

3) There's a lot more to describing a system than just definitions (I'm referring to your backtracking algorithm for generating a system description). Your idea has some good merits since, if applied correctly, it would lead to a consistent set of logical predicates. This set could be, theoretically, mapped to a class structure. In fact this is what UML is trying to do, but instead of using words and statements is using diagrams.

4) "classes and functions should be kept as small and generic as possible" Too generic equates to useless. Concrete actions are always specific. Small (simple) equates to inefficient.
 
5) "classes and functions should be designed with reuse in mind but without superfluous functionality reuse of existing classes and functions should be done as much as possible" Reusability was the Grail of design & programming. It still is.

6) "refactoring functions and types during design is cheaper (in terms of programmer time) than during implementation" True. But no design will deploy as 100% working code. There is a fine balance on how much you design and how much you test your design by implementing it.

7) "Apart from that the other rules of extreme programming may, or may not, be applied at the discretion of the developer." What are you actually saying? Should I go to the left or to the right?

8) "No software development methodology is complete in of itself" This is a true statement.

9) After reading your article I still don't know where to start implementing IDD as part of my development process and what are the IDD steps that I have to go through to finalize a design.
Dino
Monday, November 22, 2004
 
 
1. Top-down analysis and design
2. Design-as-you-go
3. Continuous refactoring

I don't mean to sound rude, but your article only seems to describe the above well-known techiniques. I suspect it was rejected because there was nothing new in it.
subhash Send private email
Tuesday, November 23, 2004
 
 
The first thing I thought: this is describing stepwise refinement.

A statement like "generic and reusable as possible" does't give the reader much to go on. What advice can you give to the reader to help them design generic and reusable software?
Tom H
Tuesday, November 23, 2004
 
 
Thank you for the comments, they are useful.
Christopher Diggins Send private email
Tuesday, November 23, 2004
 
 
"Small" and "generic" are always pretty much opposed. Generic means you handle more cases, which almost always means you have to add code to do this (unless you can handle many cases in exactly the same way, in which case 'generic' is a no brainer).

That's why we have the agile methodologies, which emphasise 'small', versus the code reuse methodlogies, which emphasise 'generic'. (Oversimplifying wildly I know - don't make this an XP thread).
David Clayworth
Wednesday, November 24, 2004
 
 
Small and generic are not opposed.
Christopher Diggins Send private email
Thursday, November 25, 2004
 
 
Miscellaneous thoughts :

1) Why "implementation driven"? Isn't it roughly hierarchical decomposition? And if I understand correctly, nothing gets implemented until you hit the bottom (ie. the smallest block / function that doesn't need to be decomposed further.)

2) This reminds me of is Paul Graham here (http://www.paulgraham.com/progbot.html) when he says that you grow your library and your program towards each other. By talking about small, generic pieces it sounds like you're talking about the library part of this two-pronged attack.

3) On the whole though, my response to your article and Graham is that these are true but fairly obvious descriptions of what most experienced programmers are doing intuitively on solo projects. The question of methodology really only arises when you add the extra complexity of larger multi-purpose projects. How do you split the work between programmers? How do they communicate? How do they identify inconsistencies in their conception of the overall design? etc.

Does this have anything to say about these issues?
phil jones Send private email
Thursday, December 02, 2004
 
 
Hi Phil,

You bring up good points. I guess I call it implementation driven design, because once I describe the high level problem, I immediately start building the simple generic functions and classes that I will need, and build up to a high level design from there. Perhaps it is more of a two pronged approach as you describe.

I am glad to hear that you find I am stating the obvious. Not everyone seems to agree that what I am writing is correct. So I guess I am on the right track, but not yet describing a methodology.
Christopher Diggins Send private email
Tuesday, December 07, 2004
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz