Wednesday, March 21, 2007

Detailed communication and Design

Detailed communication and Design

Software development is not manufacturing, there is no the dichotomy between “design” and “production”. The whole thing is “design”.

I know the above for a long time. However, it is more and more difficult to keep the belief -- because of outsourcing (I do not see any other real reasons), programming is more and more perceived as cheap labor, instead of a professional activity. As a result, I am more and more thinking about the meaning of “design”. Also, because the essence of RUP is aligned with “manufacturing” thinking (I know, this is a big generalization), I think more about XP’s “design”. However, although refactoring puts “design” in the center, the general perceived theme of XP is “less or even no design”, so, it is really disappointing. Then, we have DDD. I am very disappointed of it (see my previous blogs); however, the fact that it puts “design” back to the center of everything is really a wonderful achievement -- by using “modeling”, it changes “requirement gathering” into “design”. So, now “modeling” and “refactoring” extend “design” to everywhere.

However, it is still not enough -- it is just a starting point: we all know the waterfall sequence of “analysis-design-coding”; if we admit that everything, including coding, is “design”, then, what does that sequence mean? Are we ready to throw the sequence away, or, does it still mean something?

I believe the sequence still means something. The following is the reason.

Business applications are complicated. The complexity is not from the inherent difficulty, but from the sheer amount of information that cannot be obviously modularized or abstracted – any abstractions higher than higher-level languages (Java, C#, VB, C++) will always be leaking abstractions.

This is the root cause that we need detailed communications, because every detail counts.

However, for communications between users and developers, even for teamwork communications among developers, higher-level languages are simply too detailed to be effective.

As a result, we need various ways to “simplify” it, to make some leaking but helpful abstractions. Those are the “designs”.

(a) There are “various ways” for design -- you can have many ways for design.
(b) This perspective paints design as “not the real thing”, this is the XP perspective.
(c) However, it also points out that it is the critical “handle”; it is the center of everything! We cannot talk code line by line; we have to talk refactoring, which leads to design itself. Also, just like higher-level languages in “coding”, natural languages in “analysis” are too detailed for effective communications. As a result, we have to talk modeling, which leads to design itself.
(d) You cannot change "analysis" and "coding" only for communication, however, you can change "design" for communication. As a matter of fact, that is the very reason that we need "design" -- wow, what an insight!
(e) Design is the key for teamwork. Perhaps you can get away without design if you develop it for yourself and by yourself; however, you need design when you have “users” and “co-developers”. In short, if you need to talk in development, then, you need to design!


Blogger Vikas said...

3/25/2007 04:46:00 PM  
Blogger Vikas said...

If all companies had IT employees like you , we , consultants would be out of business.


3/27/2007 06:18:00 AM  
Anonymous Anonymous said...

I always believe consulting is the role model for every real developer: always on the cutting edge, pick domain knowledge quickly, do the job, and move one … Sadly, I see that a lot of – if not most of -- FTEs cannot do that, they use domain knowledge as the excuses for the extremely low productivity and inefficiency. They are effectively holding the company in hostage! This is the root cause that more and more companies are seeking out for consulting companies. You say, come on, where is your party line? OK, I believe I am a consultant within the company; I have been moved around on different "subsystems" very often, willingly or no-voluntarily ;-)– once you have the reputation, then, you will be moved around often. I believe that is perhaps a good compromise. Another compromise is that the consulting company has some vertical focus.

As a result, I have seen many failures, and have done many “rescuing or turning-around projects”. Bad projects are bad, of course; however, they are good for learning: although successful projects are important to develop techniques; it is in those rescuing projects that you really learn, and, those things you learn are literally expensive lesions, and you will never forget!

This design blog is from a very bad project. Before rescuing this project, I could never imagine a large project could have no design, therefore, I could not appreciate the communication and teamwork functions of “design”. In this bad project, all teamwork and communications were broken down -- between users and developers, and among developers, people are alienated, hostile, and angry to each other, everybody, no exception at all – including people we knew that were nice, now they all act almost like mutant and mob, because there is no modeling/design.

You may ask: what was the rescuing strategy? Sigh, because it was so bad, and the deadline was right there “next week”, so, it was basically “bite the bullet” – still no design. Everything is done around a centralized excel bug list (yes, "centralized" -- that was the improvement in the rescuing). However, the deadline was pushed again and again and again (OK, you got the idea!). If we knew it ended with so many delays, we could do more design … So, here is another lesson: later is better than never. Never too late to do it right, now. Do not assume the nightmare will be over "next week" – it could last for two months!


3/31/2007 07:41:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home