glad to see more people spreading the paradigm that software != construction

http://www.yinsochen.com/blog/2006/12/22/software-is-not-construction/

http://www.yinsochen.com/blog/2007/01/04/software-is-not-construction-ii/

Cheers,

yinso

For #3, Devs that join their team, how easy to maintain those objects? It’s pretty easy as the projects already has a good framework.

for #4. Yes, we have lot of their unit tests to use as code sample for UI team, but we only use it for complex screens.

The project I am working on, It has been running more than 2 years. There are 7-8 class libraries have been created with thousands of domain objects. But surprisingly, there is no design document at all. (Let’s ask aPhongBui, he knows about it; he’s joining the team to produce some more thousand of domain objects )
How can they survive? Did they do the design?

In summary, let’s design enough, document enough, move forward, and revise the design later if it’s necessary.

P.S. we may open a topic about “How much design is enough?”

The point of this topic is to argue about:
1.    Which is the essential output of the design process? Answer: the code is, not the diagrams. (Note that while the code is the essential output, I do not deny the value of intermediate output such as UML diagrams (or some sketches on the whiteboard as you mentioned) because they help bridge the gaps between requirements to the code, i.e. the design process’ final representation and offer a high-level overview to the design aspects of the software. As you say “It varies a lot but it does have a role”, I totally agree with that.)

2.    What is actually the code? Answer: the design final representation which can be used by a compiler to produce working software. Yesterday, it was assembly, today it is Java/C# (or whatever), tomorrow it may be UML.

This topic is not about how much design we should do. And as to your suggestion about the topic of “How much design is enough?”, I’ve already had a post about YAGNI (You Ain’t Gonna Need It) which does in fact slightly address your question). Please read and share your thoughts on it.

The project I am working on, It has been running more than 2 years. There are 7-8 class libraries have been created with thousands of domain objects. But surprisingly, there is no design document at all. (Let’s ask aPhongBui, he knows about it; he’s joining the team to produce some more thousand of domain objects ). How can they survive? Did they do the design?

That reaffirms the proposition that: the focus of the design process is the code itself, not the diagrams. That is a live example of the fact that projects can be successful by having programmers continuously refactoring the code, separating concerns, and properly managing dependencies to make the code clean and maintainable, instead of elaborating the UML diagrams.

On the other hand, your project sounds very interesting and I would love to know about the followings:

1.    How complex are these objects? What domain are they in? Are they simply data (transfer) object or do they contain behaviors? Can they persist themselves or are they plain old Java/C# objects?
2.    How are they designed? I.e., is domain-driven design applied? Are they coded in a high-level languages (C#, Java) or expressed in some domain-specific languages?
3.    How easy is it for a new developer to jump in and maintain these objects (given the fact that there is no design diagram to start)?
4.    Is there a high-coverage unit test suite to serve as live documentations to the objects’ API? If not, then how developers can discover the published interface of a certain object (i.e. Javadoc)?

Again, thanks for you comments and hope to hear more feedbacks from you.

Regarding your disagreements, let me address both of them

1.    While I say the focus should be on the code, I also mention that the diagrams (UML and the like) do in fact have their value e.g. the most obvious value of these diagrams is their expressiveness. In fact, I would love to learn about any software architecture firstly through the high-level design diagrams instead of diving immediately into the code. However, the point is that the code is the essential output of the design process while the diagrams only help to demonstrate ideas in a high-level perspective. (As I just mention, diagrams are useless unless the code has proved otherwise.)

2.    Think of it this way, the Java compiler’s job is to translate Java source into bytecode which will in term be JIT-compiled by the JVM into assembly code for the specific computer architecture. We do not have to write bytecode nor do we have to write assembly, they are just output of the “workers” (or “builders”) - the Java compiler and the JVM. The only code that we have to work with is Java and we call it the code. As advances in the software field allows us to express design concepts in a higher level of abstraction, e.g. UML, then it is the job of the MDA “compiler” (let’s just assume MDA can make it way into the mainstream) to generate Java or C# source code from a platform-independent model (PIM) which is possibly expressed in UML (or any other supported modelling languages). With that, we design and code in UML, not Java or C#. And thus, UML can be considered as the source code and the MDA “compiler” is actually the compiler for this language.

Thanks again and hope to hear more opinions from you!!!