It isn't all about the code?
This is the coneblog journal and related categorized archives. You can read the blog as written back to front, or browse the categorized archives at right - check out the about categories for guidance on that is where. For a quick overview of the types of content you might run into, check out the Best of coneblog - some of my personal favorites.
Entries in Thinking about Projects (2)
Problems with Highly Structured Projects
Highly structured projects seem to work for other crafts, not so much for software. Why is that?
Projects with well-defined, sequential phases are often described as “waterfall model” in the software industry. Projects structured in this way are the standard in construction, for instance. In Construction, you absolutely have to erect the structural steel before you pour the floors. But in software, waterfall projects were found to suffer from several problems:
- It took too long to define every detail of the project in Requirements or Design form. Once you did, there was a whole maintenance cycle around the documentation.
- The design process was often carried out by technicians who didn’t understand the business objectives and organizational barriers, and key insights were missed – until the system went live, when the flaws were all too apparent – reference my eight guys in a room post.


Project Comparisons and Project Dependencies
In comparing projects, one aspect I’ve been thinking about is the level of dependencies.
Where I live there are a number of road construction projects going on right now. Seems like this has been the case for several years. When driving around the traffic cones, movable barriers, and temporary roadways around the grading or bridging, I think about project management ( -- doesn’t everyone?).

