I’m going to attempt to amplify what I said yesterday by showing how a development process is organized around several levels. These levels really represent a hierarchy of abstactions which a project must define and utilize.
At the lowest level is the Language. In most cases this comes to you as a black box and in most cases it works. If you’ve been around a while you have faced the situation where the compiler has generated bad code for you. But If you are human and you aren’t working on some esoteric platform, then that happens about 1/10,000th of the number of times that you write buggy code.
The next layer is the layer I wrote about yesterday, what I called the progamming model or the Toolset. This is really composed a few things:
- A set of decisions about how or if to use the features of the language
- Some low level utility code (logging, basic typedefs, containers)
- Your build system
- Your source code control system
The choices you make in defining all of these things might be colored by the demands of your particular project, but in and of it self this layer doesn’t really provide any features.
Features start appearing in the next layer. Libraries, whether 3rd party or internally developed, provide functionality to the application and access to resources in the platform. Most programming languages include a libary of code as part of the bargain. Some of them, like the C library, are quite low level and really are part of the Toolset layer. Others like the libraries that are part of Java, Python or C# (.net) are a rich platform of code to build on. When these libraries are well designed for your task they are responsible for a huge part of the gains in productivity cited by the advocates of these systems. The lion share of the rest of the gains is due to garbage collection.
The next layer is Architecture. This is the one that sounds the most impressive. System Architect looks better or your resume than just “Programmer” or even “Software Engineer”. Here’s where the block diagrams begin happening so this is likely to be the lowest layer which upper management bothers to pretend to be interested in. You have to decide how the pieces that you are assembling will fit together and interact. This is not just important for how the program will work, but also for how the programming team will work. It often happens the members of the development team will be placed in groups according to the block diagrams you draw. You need to be sure that the key parts of the project, especially any risky ones, have very well defined boxes with very well defined leaders. During development for each key part of system you need to able to identify the person who’s responsible for it.
The highest layer is Feature Set. What does the product actually do? When your project is trying to do something really new, the question is genuinely hard to answer. Depeding on your specific sitation the form this specification takes(if you even have one) can vary alot. Alot of design at this level is of the form: “We need to have an drop-down whatsit like turboFoo does”. This is ok. The thing to really be afraid of is when there isn’t a good process in place to make the choices. Generating options is Brainstorming, Design is choosing between options. Its very easy to get the two confused.
One last thought. With all these layers to consider, what order should they be approached in? Bottom up or Top Down? I actually think its best to do both. You can starting building up your Toolset before the block diagrams are all done. Besides, its a great way to take a break from those all day Architecture and Feature Set meetings.
Leave a Reply