Ken Orr's advice to Java programmers (and the secrets of writing good software)

(Cross posted at my java.net blog)

Recently I had the pleasure of sitting down with Ken Orr (of Warnier-Orr Diagram fame) to discuss his views on software design and on what programmers really need to know.

In the 1970's, Ken Orr expanded on Jean-Dominique Warnier's methodology to develop Data Structured System Design (DSSD).

DSSD is primarilly a data driven methodology for designing systems with (gasp!) direct user involvement. Through the use logic and data charts that are easily explained to the users, the requirements of a project are collaboratively captured in a format from which much of the code and data schemas can be generated... This may sound like "no big deal" today, but Ken published these techniques in his book Structured Systems Development in 1977.

Ever the opportunist, I cornered Ken during lunch one day to pump him for insights (as fodder for this blog)...

John: "Ken... What advice would you give Java programmers?"
Ken Orr: "Don't define yourself as Java programmers."

I am going to have to paraphrase from here on out... both because Ken is from Kansas, and because I wasn't taking notes (and I didn't think to bring a recorder).

Being a good programmer really has very little to do with the languages that you know... Being a good programmer is mostly dependent on the methodologies that you know and on how you employ those methodologies.

Good process design skills and good data modelling skills are the foundations for being a good programmer.

This holds true whether you employ Object Oriented Design, Aspect Oriented Design, or Service Oriented Design. If the process is not well engineered, or the data model is not well engineered, "you are just putting lipstick on a pig".

Process design and data modelling are best done in collaboration with your users (Don't confuse this with letting the users design the process or model the data, both require considerable skills that aren't easily mastered).

Ken offered this advice when developing a new design with a client:

It is better to be clearly wrong than to be obscurely right.

If you have something wrong in your design, and it is clearly wrong, then your client will point it out and you can correct it. If the design is obscure, the client may never know if it is right or if it is wrong.

Tools are the key for communicating with your clients... processes (and data) are expressed well through pictures (flow charts, etc.), and you are missing the boat if you don't adopt tools that map these pictures to code.

I got the feeling that Ken's biggest regret is that Computer Aided Software Engineering (CASE) seems to have been on hiatus for most of the 90's and the first years of this century. Model Driven Architecture is surely a form of CASE, but Ken feels that the focus isn't quite right.

UML was developed to meet the design needs of programmers. We need tools focussed on meeting the design needs of users.

This led us into a discussion of SOA and BPEL. Ken is very "hype-sensitive", and cautions that SOA must be understood before you take the plunge.

One of the most promising aspects of SOA is that it brings the art of process design back into focus. In many cases, each service can serve as a step in a process, and BPEL can be used to describe the process itself.

My (John, not Ken) own spin on the process/services connection is the following: By viewing each service as a step within a larger process, you can get a "feel" for the correct granularity of the service interfaces...

• If the granualarity of the services is too fine, then the process definition will probably have too many steps.
  
• If the granularity of the services is too coarse, then you won't be able to modify the process without modifying individual services.
  

Ken's parting advice was perhaps the most important thing to remember...

Master more than one design/programming paradigm.

No paradigm is perfect... that's why there are so many of them. Each fills a niche, and in some cases you might need to apply multiple paradigms to solve a single problem.

Ken gave the example of AOP vs. OOP. Objects are very good at solving "vertical" problems... Hierarchies of relationships being the most common. Aspects are very good at solving "horizontal" problems... Cross-cutting concerns require thinking beyond object boundaries.

I suspect this is why Ken has never become too old to program. By mastering the basics of data modeling and process design, and by mastering newer paradigms as they are developed, Ken has remained a vibrant force in the programming world.

I don't want to make Ken blush, but in my book he's a darn good role model.