Methodology for Non-Programmers

Most of my customers are “Big IT” – most of whom aren’t comfortable with Agile methods.  They like Big Design Up Front (BDUF), detailed plans, specific dates far in the future, and gigantic deliverables.  Here’s another nail in that coffin.

Sadly, the article doesn’t mention the biggest mistake the corporate IT makes in project management.  The label almost all changes to a project scope as “failure”.  Any Agile technique will lead to learning, which leads to scope changes, which – alas – is failure.

Centuries ago – it seems – Jim Coplien facilitated a session for us at CiliPLoP .  It was life-altering.  Really.  Almost 10 years later, I think I’ve found something equally cool.

Object modeling is hard.  Objects are characterized by their attributes (or internal states), associations, and operations.  There is a tangle loop between object identification and state identification.

Recently, I’ve fielded some questions on locating the state transitions for objects.  In the SOA world, we are sometimes trying to understand composite objects, and characterize the services we should provide and the state transitions they can undergo.  In the Java Composite Application Platform Suite, one message-passing technique is to accrete information into a large composite object.

In another instance someone claimed they had 800 states.  This, it turned out, was a bluff and the users quickly whittled the list to a mere 80 states.  This is still crazy, since people can rarely comprehend more than a dozen of anything; the magic number is 7±2 .

And overcoming Ignorance takes (a) time and (b) understanding what you don’t know. See /dev/null ‘s post on Gestation : architectures don’t arrive overnight.
I’ve seen two interesting techniques recently for avoiding problem-solving. Thought I’d like to pass them on to anyone else who feels lazy.
This is a quick overview of one approach to object modeling. It provides a course of action that, as a minimum, serves to prevent “designer’s block”; it helps identify where to begin.
The deployment process installs and configures software so it can be used to create the promised business value.
The implementation process implements (or constructs) the software. Once implementation is complete, the final deliverable is a document describing the deployment of the software for actual productive use.
The design process is similar to other object modeling exercises, carried out at a much lower level of detail. Final implementation descisions are made during design. It permits us to go forward and create other deliverables for implementation and deployment. A design document presents the packages and classes that will be purchased, downloaded and constructed.
The architecture development process identifies a candidate solution to the problem documented in the Requirements. Once the architecture is known, then additional deliverables leading through design to implementation and deployment can be created.
The process of requirements analysis has two goals: complete the document template and understand the problem. Completing the document creates a structured framework for exploring the problem and capturing information. The problem and its solution are only understood through a written description. Ultimately, software development is an exercise in knowledge capture.
Programming delivers software, but prior to that, it delivers a reasonable plan that shows that the software really will solve a problem. This document describes a set of deliverables that is a workable level of documentation, consistent with best industry practices.
Building Skills Content Management Culture of Complexity Data Structures and Algorithms Databases and Python DocBook Economics of Software Macintosh Methodology for Non-Programmers Open Source Projects Personal Web Toys Technology News Test Driven Reverse Engineering The Lure of XML Unit Testing in Python User Interface War Stories and Advice

Previous topic

Not the first time...

Next topic

Getting to an Agile process

This Page