October 24, 1998 - Jack Harich - Home Page
A good software development process can improve the productivity of an individual or group by an order of magnitude. Which process for which group for what type of work, how to avoid the complexties and downsides of formalism, and how to best hit high productivity are tough questions.
We address these with a novel answer that unifies the role of architecture, continuous change and ultra-high reuse in a development process.We use the definition:
|
Process - A systematic series of steps to do something well. |
First we lay the groundwork.
IMHO popular processes are addressing the wrong problem. They are product life cycle oriented, such as analysis, design, construction and testing, or inception, elaboration, construction and transition. They are also project oriented, but 75% of coding is maintenance. What is needed is a process that directly and strongly supports one's architecture and continuous change. Otherwise our software is project driven instead of process/architecture driven, and we cannot support the change rates demanded by market forces.
Here's the master model of how to do it.
This document presents the Change Process and System Architecture model. This is an attempt to combine process with architecture and continuous change, with the goal of ultra-high reuse and very fast development. This document contains deep thoughts and is not an easy read. These thoughts are the next logical step in my work, building on the Bean Assembler and its use of declarative knowledge and a domain neutral system microkernel.
Take a long walk and ponder this document after you've read it.
Don't rush a thing.
Digest it completely.
Then decide if you think it wlll work well.
A huge hurdle for most organizations and individuals is where to start. Given that most are at CMM Level One, aka Chaos Canyon or "Unpredictable", we recommend starting as simple as possible. My Mini Process is very digestible. It takes about 2 hours to introduce a small group to steps 1 to 7 (requirements), using a real world subsystem as an example. The rest varies depending on whether they are new to GUIs, modeling, and disciplined testing. Here's a detailed description of the Mini Process.
Note the steps for Use Cases, Traits and Risk. These provide a powerful three dimensional analysis, and seem to encourage early discovery and understanding of all important requirements. For small or high level work it's great to get the requirements and model steps on a single page.
The big thing the Mini Process does is get people to do detailed preparation before diving into code. It's a matter of Plan Your Work and Work Your Plan. Most are not used to doing this. Colleges are not emphasizing this. Instead they focus on coding. As I often say, "The battle is won or lost at the design stage, not coding."
| >From David Hecksel, 9/12/98 on the JSL list, in response to this Mini Process I also have experienced such productivity gains. I started using this approach consistently after taking a 12 week education class on Object Technology 3+ years ago (IBM's Object Technology University for those who might be familiar with the program). 12 weeks, every day, immersed, 1/2 programming, 1/2 material (and getting paid to boot!). My opinion is that the approach Jack outlines in his list below works best (optimal productivity gains) with more than two people working on a project, although there are gains with two or less as well (just not as much compared to the prior "jump to code" approach with a small or individual project). The clarity one has when going into code if you follow these steps is enlightening if you have not experienced it yourself. Code integration among team members becomes a non-event. Rework is almost eliminated. |
The second version is the Mini Process Grid. Here we introduce much, much more process definition by adding step objectives and deliverables, plus more emphasis on testing. This is an example of how to capture any process on a single page. This improved version is based on a process example provided by Ron Brown and Britt Kinsler. Thanks!
For a pleasant surprise, we briefly present a very powerful, very simple technique called Structural Tension. While the Mini Process is for creating systems, Structural Tension is for the planning step of any significant endeavor.
To get individuals motivated and started in the process of self improvement, this Daily Worksheet can be explained, discussed and practiced quickly. The "Top Objectives for the Day" are the most important feature. They train the mind to work in an organized, proactive fashion. More mature organizations or developers will not need this worksheet. Some will have to modify it.
At the beginning of each day I sit down with my notebook, flip to the Daily tab, and complete the "Status at End of Day" column, if not already filled in. Examples are Done, Next Day, Delegated, 2/3 Done and Done but Needs Confirmation.
Then I take the time to ponder a bit and fill in the rest, which is self-explanatory. Then I start a new page and list today's objectives and tasks. I average 3 objectives. The list is large to also allow listing tasks at the bottom. These are not objectives, but minor tasks like call Bill, find a certain document or revise a certain model due to a brainstorm.
One can also do all this at the end of each day, and review the list at the beginning of the next day. Many recommend this, because one's mind is fresh with what needs to be done.
Once the lessons from the Daily Worksheet are learned deeply, the individual or group can improve the document or accomplish the same thing in other ways. This exercise does wonders for establishing a culture of learning and improvement.
Suprisingly, in practice some individuals react negatively to the worksheet. I'm guessing this is due to no explanation, a poor explanation, or maybe the words "Personal Growth". Or it could be the manager saying "I'm going to collect them at the end of the week", leaving the person wondering if they are going to be judged. I'm investigating this. But most react positively. Some react so well they revise the form, tuning it for themselves, complete with their name.
Process Assessment
Suppose you need to do a simple in house assessment to see where a group is. The Process Assessment serves as a straightforward self assessment. It is designed not for numerically determining where to go, but to serve as discussion material that points in a general direction, or exposes micro areas that need attention. It can also serve as the starting point for a custom assessment.
Core Competence Analysis
If you're getting really serious about improving your process, you also need to analyze and improve the specific skills that make your organization truly outstanding. This is also know as Core Competence Analysis. We offer a brief coverage of this subject and some compentency tables to get you started in minutes. This makes for a good management excercise.
Development Process Overview
Now we tie it all together with an overview showing the process as a whole. The diagram shows the process being used for product development, its most common use. Milestones and documents are listed on the diagram so one can clearly visualize the process. An explanation of the phases and documents is included.
Defined Process
If you want to kick off a Defined Process in your organization, read this one pager. It's a summary of how to design a Defined Process. Then study the literature and specific processes others have done, until it all makes sense. Then do your own first iteration....
Higher Level Processes
Once you understand process, it's possible to grasp higher level processes. A portion of this page presents a range of processes, from Coding Cowboy on up.
Here's a minor document written as a thinking excercise. It preceeded the real work of designing the Change Process and System Architecture model, and identified crucial abstractions. A fun read....