In Part One I dissected why Enterprise software development groups deeply compromise their productivity by letting combinatorial complexity snowball out of their control. Since complexity tends to grow to unmanageable scale, how can groups break it up successfully? How can the complexity be managed?
One way to look at it is by viewing the central problem of software development as: How do you break a large project into individual pieces that can be worked on in isolation by small teams yet bring those pieces together into a unified whole?
First, we'll talk about how to break things up. Then, we'll talk about how to bring things together into a unified whole.Continue...
If you work in any kind of medium or large company that isn't a software company it's probably pretty obvious that the software developed for the business in-house is vastly inferior to the software you use in your daily life, mostly on your phone. In-house development ("Enterprise" development) takes forever to deliver crap and software companies "get it" whatever "it" is.
There is nothing new about this. Brooks starts off The Mythical Man Month examining exactly this phenomenon and he wrote in the early 1970's about his experiences at IBM in the mid-60s.Continue...
This year I find myself fighting a lot of the same battles. Mostly for my own amusement, I dug out some old presentations I use to give. It's surprising what has changed and what hasn't.
The formatting of these is bit rough. These were authored in Office 95 and it took some doing to get them opened and converted even into this format.