 |
Ken Orr's advice to Java programmers (and the secrets of writing good software)
Posted by johnreynolds on March 17, 2006 at 01:49 PM | Comments (7)
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 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.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Considering they are using screenshots from Microsoft paint for most designs, oh yeah we need improvement.
Posted by: smartinumcp on March 20, 2006 at 09:59 AM
-
Ken, you make some very good points and for the most part I agree with you. I'm not so sure about SOA bringing process design back into focus.
Don't get me wrong, process design is vital to good software design. It's just that we've been using programming techniques that emphasize process design since the advent of functional programming. We speak in terms of objects and methods today instead of functions and data structures, but the problem remains as you put it: "If the granularity of the services is too fine, the process definition will probably have too many steps", etc. A service is a method is a function, conceptually, so SOA will have the same problems. SOA's problems, however, will be exacerbated by network latency, but I don't think that will be sufficient to refocus developers on process design.
What we really need to do is beat into developers the importance of balancing code complexity against interface usability, and I think we'll wind up with better-designed code in all domains, not just SOA.
- Trevor
Posted by: trevorwilliams on March 20, 2006 at 10:08 AM
-
Trevor,
Ken really is talking about data modeling, and would not equate that to object modeling.
In Ken's view, objects impose a hierarchy on data, and he has found that normalized data models are genuinely better in the long run (an object can be thought of as one specific view of the data).
Being a mostly object-oriented person myself, I would have taken issue with Ken before looking at it from another perspective.... sometimes data is "just data", particularly when it is being used by many disparate systems. Think "ad-hoc query" and "data mining" and Ken's views are easier to understand.
I think the important point is to not get trapped into either "object centric" or "data centric" thinking... both have value.
--JohnR
Posted by: johnreynolds on March 20, 2006 at 10:26 AM
-
John,
Sorry I called you Ken before. Chalk it up to caffeine deficit.
I understand what you're saying about data modelling vs object modelling. My previous comment was targeted specifically at your statement, "One of the most promising aspects of SOA is that it brings the art of process design back into focus." I just spewed my thoughts about code design and forgot to talk about data, thereby helping you make your point about paradigm awareness. No thanks necessary. :)
As it happens, I'm in complete agreement with you and Ken on that point. Mostly. While I think it's often true, I don't believe that objects impose a heirarchy on data. Designers impose that heirarchy, and if the same designer is doing the code, chances are the data heirarchy will match the object heirarchy, whether it's appropriate or not. As you said, data is "just data". It doesn't do anything, its heirarchy needs to reflect its shape. At a low level -- DAOs for instance -- the object model will reflect the data model, but at that level the objects are merely a bridge and therefore don't count as part of the object model. Above the data access level, the object model needs to reflect the use to which the data will be put. A hospital's medical database, for instance, may be used by a doctor to examine or update a patient's history, by the billing department to send out invoices, by the pharmacy to cross-check for drug interactions. One data model, many object models.
Maybe it's just the semester of Lisp I took almost 20 years ago talking, but consider for a moment that when you decompose a complex method into smaller pieces, what you're really doing is normalizing your code. You then see that object-centricity and data-centricity have value because they're two sides of the same coin.
Tha's my opinion, at least. Let me know if I'm full of crap.
- Trevor
Posted by: trevorwilliams on March 20, 2006 at 12:43 PM
-
That is a fantastic and expressive gif you have there. I'm always amazed by how such simplicity isn't favored above crowded flow control diagrams that look like circuits. Across the board, modern enterprise development seems to be clouded by box and cylinders and many arrows and hundred page requirements documents. Myself, I would present such a diagram to our business team if I were allowed to.
Posted by: ilazarte on March 20, 2006 at 02:50 PM
-
are there any o.s. warnier-orr tools of note out there? i did a preliminary search, but didn't see anything.
Posted by: ilazarte on March 20, 2006 at 06:12 PM
-
I don't think it's open source... but there is a Warnier-Orr tool called "brackets" mentioned at The Ken Orr Institute.
The screenshot that I included is from a tool called B-liner.
Posted by: johnreynolds on March 20, 2006 at 07:25 PM
|
java.net RSS Feeds
