posted on Wednesday, June 02, 2004 2:09 PM by roydictus

About Smart Development

Hi everyone, and welcome to my blog. Here you'll regularly find new short pieces about Smart Development with .Net.

Smart Development isn't some new methodology or framework such as Extreme Programming (XP) or Microsoft Solutions Framework (MSF). It's just the name I give to a set of best practices, combined from XP and MSF, and some own observations added in. Moreover, it differs from XP in the way it looks at planning and teaming, to name a few. More will become clear in the time to come, on these pages.

The goal of Smart Development is simple: to give development teams the guidance to develop the best possible software, in the shortest time possible. Time is money, as they say, and that is certainly true in the software business. Many projects get canceled simply because they run out of money, or because of very poor planning. XP, MSF etc. try to minimize such risks. For example, XP says "don't do any planning more than 2 iterations ahead." I almost agree with that, but I think the very first phase of a project should include at least good guesstimation of the costs and features of a project -- and good guesstimation is derived from some form of plan.

Basic principles of Smart Development are:

  1. Iterative development: projects are developed in short iterations (1 to 3 weeks, tops), and iterations alternate between "new features" iterations and "bug-fixing/optimization" iterations;
  2. Quality comes first: for every decision to be made, always put the quality of the output first. One direct result of this principle: you don't add new features to your project if there are still known bugs that have not been labeled "acceptable". Another one: automate as much of the build and development processes as you can, as long as it's (pragmatically) justifiable, because nothing is as common and expensive as human error;
  3. Build process: with daily or multiple-daily builds as the heartbeat of the project, teams know that their software builds and integrates correctly. I personally don't like the idea of XP's Continuous Integration very much because I think it is applicable only to smaller projects, but a twice-daily build, for example, makes perfect sense even with larger projects. One of these builds is the full build, including all unit tests, complexity metrics, FxCop tests and what have you, whereas the second build runs less tests and can be considered merely a "smoke test" before the real "daily" build is started;
  4. Focus on provable correctness: unit testing is super-important. It is necessary to test the quality of new features, for regression testing (making sure new features don't break existing ones), quick-fix engineering and progress tracking;
  5. Progress tracking: progress needs to be tracked; not just the measurement of which features have been added etc., but also the number of new vs resolved bugs, the complexity of the software produced etc. need to be measured continuously. Especially for project leaders: never let the question "so how's your project going?" surprise you -- instead, answer with hard facts;
  6. Documentation: as part of progress tracking as well as making sure users will know how to use the software, and developers will be able to maintain the software in the future, documentation takes a primary position. Yes, we programmers hate to write documentation, but we hate to maintain undocumented code even more. Included in the documentation principle is, of course, the central availability of information and documentation to all: easy to find and complete;
  7. Know what you do, and do what you know: all work should be divided up into small, individual tasks that are either complete or not counted (i.e., they are never "90% done", but 0% or 100% done), and work should be done by those who are most qualified to do it. XP states, for example, that everyone should be able to tackle any task and assume any role in the team. I respectfully disagree. I think that, especially for larger projects with larger teams, specialization is an important benefit. Not everyone is as good a DBA or as good a low-level coder as their neighbor, and I think pragmatic teams should recognize that and benefit from it.

We'll get into detail in the coming months and years on this blog, on every one of these subjects.

Of course, comments and suggestions are always welcome. You can leave them here, straight on-site, or you can mail them to roy@u2u.be.

Many thanks,

Roy

Comments