Component-Based Software Development

Around 1800, Eli Whitney proposed manufacturing rifles with interchangeable parts, instead of crafting each rifle individually. Widely regarded at the beginning of mass production, the concept of interchangeable parts led to a dramatic increase in rifle production capacity while delivering the additional benefits of consistent operation and easy field maintenance of weapons.

Component-based systems represent a paradigm shift in software development similar to that of using interchangeable parts in manufacturing. A component-based system is built of standard, reusable parts that become the fundamental building blocks of future software. Component-based systems promise numerous benefits, including flexibility, scalability, and maintainability.

The promise of component-based systems has been difficult to realize. The reality is that even through the last decade, monolithic systems have dominated corporate IT. And after a few years, monolithic system become legacy systems, because they are not flexible, changeable, or easy to connect to other systems. A company will get acquired or acquire other companies or spin off divisions, and all of a sudden, the monolithic systems get in the way of progress.

During the 1990's more software by far was developed for the Internet that was developed for all the corporations in the world. But Internet software was typically developed vary rapidly, with expediency taking over where architecture once reigned. And guess what - Internet software is largely component-based. It may seem like heresy to 'true' software developers, but an Internet startup could get a shopping cart and a search module and a merchant account and a product display package from other Internet startups. There is Mapping software and travel planning software and collaborative filtering software, and when you look at it closely, these are true components. Web sites can be rapidly manufactured with 85% components, 15% glue.

Now it's time to bring components to the corporate world, and they are headed our way under the name of Web Services. Here's a quote from the January 3, 2002 CBDi forum newsletter:

Web services provide formalized separation of concerns at a usable level of abstraction and you can implement web services right now with most of the current versions of platforms and software tools. Web services are fundamentally a low-cost technology investment that easily extend what you already have to provide real business value. First look for internal applications, there are many opportunities to simplify internal integration. Second look externally at public (non secure) or private B2B applications, and make sure those security and privacy budgets address the needs of Web services. Look at the Web services that IBM and Microsoft’s customers are already delivering.

Theory of Constraints

Two decades ago, Japanese car-makers developed several new manufacturing methods, including 'Just-in-Time'. Based on the theory that most in-process inventory spends most of its time in a buffer, waiting to be processed, Just-in-Time scheduling dramatically reduced inventory, which coincidentally reduced the amount of time it took product to move through a manufacturing plant.

In the 1980's, Dr. Eli Goldratt publicized the Theory of Constraints, which improved upon Just-in-Time methodologies, and in the 1990's, Goldratt adapted the Theory of Constraints to project management in his book "Critical Chain". Based on the idea that individual estimates of project time must be padded to allow for contingencies, Goldratt demonstrated that padded project time operates in the same manner as inventory buffers to delay projects.

It's Okay to be Late
The fundamental concept behind the Theory of Constraints is that elements of a project must be scheduled based on the average time they will take to accomplish, not the maximum time they might take to accomplish. A project buffer is placed at the end of the project, which allows for some activities to be late.

Of course, it's human nature to estimate time based on the worst case scenario, not average time to complete. As soon as people are penalized for estimating average time and then not meeting the estimate, they will revert to estimating the maximum time, and project schedules will again fill up with padded time estimates. Thus, in a project using Theory of Constraints, it is important that it is 'okay' to be late.

It may be hard to buy at first, but even though it's okay for individual elements to be late, Theory of Constraints project management makes it far easier to assure that the overall project is completed on time.

Last Planner

The Lean Construction Institute has developed an effective project management technique for construction called 'Last Planner System'. This is a deceptively simple system which involves having foremen (last planners) planning activities for the immediate future, using only two rules:

1. If it can't be done, then don't plan to do it.
2. If you plan to do it, then get it done.

These two simple rules, along with a similar set of rules for the period after the immediate future, have led to enormous productivity increases in construction. For more on this visit the Lean Construction Institute.

Screen Beans Art, © A Bit Better Corporation