Saturday, February 17, 2007

Creativity and competent People

I listened to an interview with Eric Evans (Author of Domain Driven Design, see also DomainDrivenDesign.org). The Podcast with the interview is available from Parleys.

He brings up an interesting observation about how software is developed today:

  • Object oriented software development is a creative process. Designing and modeling needs a lot of creativity. Only with creativity we can develop a model that really “crunches” the domain-problems in an elegant, maintainable and extensible way. This creative process is a heavy work and needs a lot of experimenting and freedom.
  • A lot of companies/shops have the goal to establish a very rigid way how software is developed. This can be with a heavy, constricting framework and/or with a heavyweight process.
  • The goal of establishing a rigidly standardized way of software development is to minimize risk: If everything is predefined nothing can be done wrong, if everything is done the same way, it is easier to maintain. The developer who uses (has to use) the framework should not have to nor be able to use creativity, because if he is creative ha can do something wrong.
  • This kind of thinking also limits the potential of real good object oriented modeling: If the framework heavily constrains the creativity of the developers no real “domain-crunching” can be applied. As a consequence, the resulting model often is not optimal, clumsy or even wrong.

I'm currently experiencing these observations on the project I am working on.

I think if there are good people working with a heavily constraining framework, a lot of potential is wasted. This is also a big risk, because if the model is flawed, maintainability and extensibility will be suffering. Also if the framework does not provide (elegant) ways to do something, developers will have to “hack around” the framework. The result will certainly not be maintainable. So in these cases using a heavily constraining framework totally missed its goals!
On the other hand if the people are not good, the framework has to be very good, to guarantee that nothing can be done wrong (but everything necessary can be done easily). I don't think a framework like this can exist… so you need good people anyway.

Well, thinking about it: If your business-problem is not trivial, you need good people to come up with a good solution… so why constrain their ability to model the problem in an optimal way?

Eric makes another interesting observation in the interview:

  • In many companies/shops the good people are working on developing the technology/infrastructure/framework, but are not really working on business-problems.
  • This is a problem, because this leaves the mediocre people to solve the business-problems and to perform the “domain-crunching”. But finally this is the real value that is provided to the customer…

I think this is really a big problem today, and companies/shops that do not change already have or will soon have real problems. Management and developers have to realize that solving the concrete business problems is the first and most important challenge. Technical concerns should only be of relevance if they are a real obstacle to solve the business problems. But technical concerns should certainly not drive your development process/infrastructure! I even go a step further in arguing that technology is not an issue any more today for most business applications. There exist standardized and proven technologies for most technical problems in enterprise development. You just have to understand and use them, but you certainly don't have to reinvent and develop them!

And now for finishing, imagine the worst case scenario: The mediocre people develop the heavily constraining framework that has to be used by the good people… where does this lead?

1 comment:

  1. I agree only up till the interface of the system.

    Where the system interfaces with humans, or other systems, we should rely on infrastructure that has solved most of the hard problems. If you're spending time figuring out the right UI paradigm for every business process, or need to put thought in how best to model every web service contract, chances are things have become too complex.

    At the system boundries, regularity of design and consistency in the design paradigm is key. Otherwise banal tasks become design efforts which create confusion, inconsistencies, and bloat.

    Allowing the ability to evolve is paramount, no doubt. But that needs to be weighed against the problems with treating a volume of problem as novel ones.

    ReplyDelete

Related Posts Plugin for WordPress, Blogger...