Teamwork and good communications cannot be achieved only by managerial techniques

Teamwork and good communications on software development cannot be achieved only by managerial techniques – including “project management techniques”. It requires some engineering techniques. Most of those engineering techniques are developed in enterprise level large projects in the past 10 years on Java platforms, and typically it will take 2 ~ 3 years to “get it” (as a result, short term training does not work).

Managers (including project managers) are certainly not responsible for the details of those engineering techniques, however, they are responsible for identifying the needs for those engineering techniques, and identifying the right people who know those techniques, and recommend them and support them – this is arguably the most important job for mangers. However, it is also the most difficult one -- because you need to know a lot to tell pretenders. Pretenders will be revealed, eventually; however, usually it is after creating huge damages, and, there is certainly plenty of supply of pretenders.

You may say, what are those techniques? For starters, techniques of modeling, designing, and refactoring, automated unit testing, coding standards, using source control and ways of using source control – they are not managerial, not even “project-managerial” (at least not the focus for project managers); however, they are crucial for teamwork and communications.

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”.

Notes:
(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!

Summary of my comments on CSLA and DDD

1. Finally I heard similar voice:
http://www.avocadosoftware.com/csblogs/dredge/archive/2007/01/28/681.aspx

http://www.avocadosoftware.com/csblogs/dredge/archive/2007/02/19/687.aspx

>>>> And as a side note, the largest problem that I have with CSLA is the idea that an entity contains it’s own data access code (commonly called the “Active Record” pattern). That in combination with the force parent-child relationships… both of those still bug the crap out of me and I’ll never use a pure version of CSLA because of them. I’m more comfortable having the data access code split out into it’s own class so that I can do dependency injection, and there-by enable TDD in my CSLA based applications.

>>>> Fortunately for me and my team, I have known the limitations of the stock CSLA framework for quite some time, and have created a highly modified version of the v2.0 CSLA framework for our use. My changes essentially, have been to remove the forced parent-child relationship and also to completely remove the DataPortal.
Note that removing “Dataportal” means taking out CRUD 4 method limitations; also, removing “forced parent-child relationship” points to removing “strongly typed collections”.


2. My suggestion for using CSLA the right way: http://forums.lhotka.net/forums/2/11975/ShowThread.aspx
(also, see my recent blogs)

3. Heated discussion about CSLA and DDD:

http://codebetter.com/blogs/jeremy.miller/archive/2007/02/23/Don_2700_t-Let-the-Database-Dictate-Your-Object-Model.aspx?CommentPosted=true#commentmessage


4. Another CSLA review
http://swcses.eponym.com/blog/_archives/2007/1/5/2622285.html


5. Similar voice on DDD:

http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx

http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/

more about CSLA and DDD

------------------my comments on http://swcses.eponym.com/blog/_archives/2007/1/5/2622285.html

by survic on Sat 10 Mar 2007 11:35 PM CST Permanent Link

vikas put the link of my blogs here above. So, I have to say something here now.

I would like to say something on the other side that you and Rocky both agree.

I read DDD many times, and I used CSLA for a long time (but you may say I bite the feeding hands, I criticize it harshly), and I used Java for a long time, while simultaneously used VB3-6 along the way.

I mentioned Java, because please do not say that I do not know OO.

My argument is that DDD, yours stand, and CSLA are all antique OO. ADM (anemic domain model) is a good compromise for modern distributed computing which is necessary for modern OO. Modern OO must be ADM!

For a large scale enterprise computing, ADM is the must. If you use “rich” antique OO, you are in big trouble.

To learn modern OO, the best way is to use nhibernate or other good OR mapping tool. Also, study java’s entity bean. Entity bean is the first mainstream OR mapping concept, it sucks; however, its key concepts are fine. Here is my recent DDD blog: http://survic.blogspot.com/2006/07/domain-driven-design-data-modeling-as.html

-------------------------Joseph's reply

by Joseph Reddy on Mon 12 Mar 2007 01:26 PM CDT | Profile | Permanent Link
Survic,

You are touching on many subjects here. The most interesting of which is this idea of “Antique OO” vs “Modern OO” with Modern OO embracing an Anemic Domain Model. For the sake of only trying to tackle one point at a time, I don’t care to argue whether one design is better than the other.

There is something wrong with stripping the most basic OO principles from a design and then calling it “object-oriented.” What you are calling Modern OO is a data-centric design with procedural code using objects that abstract the database. Again, I’m not here to argue against this approach, only to note that it is not an object-oriented approach. The ADM is a completely different kind of design where objects are no longer the focal point of the application, rather, they exist simply to get data in and out of the database.


--------------------------------my reply's reply
Reply
Re: Re: Re: Re: Book Review: Expert C# Business Objects: Rockford Lhotka: Part Deux
by survic on Tue 13 Mar 2007 12:35 AM CDT | Permanent Link
1. The huge part of my argument is actually not technical, it is perspective. If you really talk to “strategic” users (stake holders), do they really care the “Applications”? no! They care about the data! All those “enterprise modeling”, “data warehousing”, all major enterprise level initiatives, they are all about data, not applications.

2. It is almost a zigzag way: (a) small vb6 (“data centric”), (b) advanced VB6 and some .net (and some confused lightweight java) – antique OO (“behavior centric”, OO purist, DDD, antique OO), (c) enterprise java (both heavy and lightweight) and advanced .net (“modern OO”, “SOA”).


3. The key idea is that it is inevitable that “services” and “DAOs” must be separated from “entities”, and “entities” must have no dependency on services and Daos. This rule is extremely important for distributed computing. This links to a very good post by ayende: http://ayende.com/Blog/archive/2007/02/27/Entities-Services-and-what-goes-between-them.aspx


4. Once you comply the above rule, then, the so called “business logic” within entities is extremely constrained, and therefore ‘anemic”. They are rightly so. There is no way out of it.

5. Those “services” and “DAOs” are obviously procedural.

6. However, entities are OO, they are just “anemic”. So, together with services and Daos, the whole thing is still OO (but not rich OO, see below).

7. It is cheating to say a model that complies the above a “rich model”. If you split “services” and “DAOs” away from “entities”, then, the model is not “rich" anymore. Please do not misleading people!

8. You may say, it is just word game. No, it has direct practical implications. One of it is using OR mapping. If you are willing to use a OR mapping tool and feel it is satisfactory (not perfect, the whole thing is to find a good compromise, trade off) to call it OO, then, you are with me; otherwise, you are against me ;-) Seriously, OR mapping is a key test stone.

9. Note that I am not saying you actually need to use OR in every project, just conceptually is enough.

10. Another thing is that, once you really know OR mapping for quite a while, you will appreciate that really the soul of behaviors is data. Further, for entities, most of the time, the deepest and most appropriate (e.g., keep it simple) objects are indeed relational, not fancy design patterns. Also, OR mapping rules take care of inheritance-relational mappings. For enterprise computing, for entities (not infrastructure coding), “keep it simple” is the most important thing. And the core of “keep it simple” is to “keep it close to relational! Note that keep it “relational” does not mean “keep it like database tables”, because tables can be de-normalized etc.


11. The so-called “logic intensive classes" is simply misleading. Keep those logic in methods. If really necessary, create some help entities, that is not big deal. Remember, enterprise computing is easy, modern OO is easy, algorithm is easy – procedural algorithm is easy, using design patterns to do it is also easy. It is not that big deal. As a result, do not over use design patterns in algorithms. Because it is easy, so, do not show off. if you really need to show off, find a infrastructure project! I studied DDD carefully, I find that if you use “keep it simple and relational”, then, most of the “deep” stuff is so naturally done -- it proves again that the "deep" stuff in “ behaviors” are simply data! – the soul of behaviors is data! the rest? Unnecessary complexity.



12. Back to CSLA. CSLA has strict regularities of its CRUD (DAOs) and services, therefore, you can say it conceptually splits them from entities, hence, I agree with you, CSLA is not "rich" -- give me a break, how can be a model be "rich" while so being constrained! However, not rich is not the problem though. It is the weirdness of those contrains that severely hurts the object model (always 4 CRUD methods, those "criteria" -- they are weird, aren't they!). Also, it has all those strongly typed collections – another antique OO feature.

13. However, I find ways to tear those things apart and use CSLA nicely.

14. OK, let's make it 14: In short, ADM is a good compromise.

An interesting example that DDD confuses people

An interesting example that DDD confuses people

The point I am trying to make is: Entities should never depend on “services” and “repositories”. “Services”, “Repositories” have to be procedural-oriented. “Rich” model cannot be totally OO. This is not even because of TDD; it is because of distributed computing. DDD confuses people about it, and that is wrong.

You may say, it is because people are learning in DDD; I do not believe so, I believe DDD confuses people by the so-called “Rich domain model”.

Here is the example.

ayende has a very good post here: http://ayende.com/Blog/archive/2007/02/27/Entities-Services-and-what-goes-between-them.aspx

In general, I agree with him mostly, including aop, or mapping etc -- the approach is lightweight java approach. I know his work is kind of competing with springframework, which is also lightweight-java-like, but heavier. I like ayende’s approach better – the lighter, the better. As a matter of fact, I feel his approach is still too heavy – because of WF, now I believe the best way is CSLA-based – but I tear it apart, I use command pattern for “services”, “CRUD daos”, “controllers” (see my post http://survic.blogspot.com/2007/02/how-to-do-window-development-in-net-30.html. Note that I mentioned window development, simply because of its window databinding support; the core design is good for both windows and web).

Ayende is closer to DDD than me. I guess that is simply because of the fact that his everyday work has more “infrastructure” factors than application developers like me, who routinely needs to leverage data in databases to get the application logic right; however, it seems that he has some reservations on DDD also, not sure though. However, the following exchanges are very interesting to support my point of view on DDD (again, please read the whole blog thread at http://ayende.com/Blog/archive/2007/02/27/Entities-Services-and-what-goes-between-them.aspx -- I only copy the a very small part here, hope it is “reasonable use”).

OK, now, really, here is the example:

@Ayende, I'm handling it the same way, but i have some doubts about where to put DAO (or Repository) calls? I can do it like you showed above, add service layer and place all calls there, but i also can inject my DAOs directly in domain objects, making service layer is needless (and still keeping domain objects testable). I just can't decide, probably because of lack of experience. I know you prefer services, but what you think about second approach? :)
# re: Entities, Services and what goes between them... 3/1/2007 10:46 AM Ayende Rahien

@Andrew,The other approach, I feel, gives too much responsibilities to the domain objects. They are still testable, but I feel that this makes the significantly more complex. I am placing the repository calls in both services and controllers at the moment.

comments on Domain Driven Design again

This is the third time I read it. I believe I finally got it – both its pro's and con's.

I have some comments before,
http://survic.blogspot.com/2006/07/domain-driven-design-data-modeling-as.html but it is still not enough.

Pro's: “Analysis” is not just “requirement gathering”, it is “modeling”, and it goes straight to “design”. DDD make that so clear by using the concept of “ubiquitous language”, deep, philosophical, yet practical. As a result, I will put this book on my recommended book list.

Con's: It claims it has fixed “Anemic Domain Model (ADM)” by a Rich domain model, but it does not! All those “service”, “repository (i.e. DAO)” indicates that the domain entities are still ADM, which is a good thing anyway (a bad name, but a good thing). You may say, then, no harm done, what is the big deal? It is a big deal, because it creates confusions for new developers. Further, it assumes and advocates a narrow-minded and antique “database is not developers business” approach; while in reality, database is the soul of the all information systems. As a matter of fact, all the examples in the book, if you take a "relational database first" approach, you will get the “deeper” (“implicit”, “insightful”) solutions the first time, with no special efforts at all! (that is, if you know the basics of OR mapping, including three ways of handling inheritance). Also, the higher the design level is at (“strategic design”), the more database-oriented it is – traditionally, enterprise modeling (e.g. Zachman framework and data-warehousing) is database oriented, and rightly so. Because senior developers tend to have more responsibilities on enterprise modeling, as a result, this book is actually very bad for senior developers also! In other words, you are looking at the wrong place if you want to have a strategic view -- find a data modeling book, or, data warehousing book!