Recent Articles

Adopting Agile/Iterative Software Development

Iterative Software Development

Choosing An Approach To Agile/Iterative Software Development

Adopting AGILE In Your SDLC Shop

iterDev Documentation Model Projects

Convert Log4Net to NLog

Log4Net integration in ASP.NET MVC

Iterative Software Development

This site is a resource for software developers on how and why your next project will benefit from the application of Iterative Software Development tools and techniques in cooperation with your current methodology.

This site is the result of 20+ years of practical experience developing applications ranging from small to enterprise scale.

Show me Iterative Software Development


Why I wrote this site

My name is Edward Campbell. My friends call me Ted. If you want to know more about me, you can view my complete profile on here:

What my profile will not tell you is that I have been designing systems and programming since the 1980s. My first PC was an independent study project to complete my college degree. It began as a Lear Terminal, a motherboard, some printed circuit boards and a BIOS assembler listing. I was attempting to port an early word processing program, WordSmith, and unique parallel keyboard / memory-mapped video combination to a new hardware platform, with precious little knowledge of what that meant. It was a life-changing experience including many memorable hours spent debugging errors in my assembler BIOS code and timing problems in chip-level programming.

Needless to say, the PC was not running until after the project deadline. I wrote up the results on my new PC and wordprocessor. The results were printed, on a converted IBM Selectric typewriter (yes, a typewriter) and sent to my project advisor. But in the eternal ways of bureaucracy, I received no credit and no degree. You know, these new micro-computers will never amount to anything. But that did not matter and still does not; because in the process, I had found my calling.

I have been building PCs, as a hobby, and programming, as a vocation, ever since. From assembler to C, C++, Java, ColdFusion, Delphi, and now ASP.NET/C#; it has been a wonderful experience. From Dbase to FoxPro, Informix, Interbase, Oracle, SQL Server and now Model Driven Design; each new technology has opened up whole new areas of possibility.

I am both lucky and grateful for the experiences I have had, the people I have known and the chance to do something I like for a living. Many, many people do not have such good fortune. This web site is my attempt to shed light on what I have learned and possibly help others as the experience of others has helped me.

Development Methodologies and the Velocity of Change

This section is part of the basis and premise of this site. It is included here, rather than on the main site, to keep out of the way of those who just want to get to the point. These are my own thoughts and are not meant to diminish those of anyone else.

Development Methodologies take on inertia of their own. Carefully-crafted department wide standards (such as mandated by CMMI and others) are becoming increasingly irrelevant. This is due to the velocity of change in technology. Department wide standards for your ASP.NET development, for example, must be re-written if your next project uses, say, ASP.NET MVC. When this happens in the course of your continuing development, it effectively reduces you to a CMMI level 2 process or increases your process maintenance burden significantly.

More to the point, what about the project after next, or the one after that? Will it be based on WPF, Bootstrap or HTML 5? Or will you switch to Java, LAMP, Adobe Air/Flash, Android, Apple IOS or any of the other technology stacks competing for your development dollars? At some near-term point, your choices will be limited to continuing with a development technology stack that is losing market and mind share - with the attendant difficulties in finding skilled developers, tools and components - or re-writing your current development process to address development in a new, to your organization, technology stack.

More likely, your carefully drawn department standard for ASP.NET MVC development will need to be 'updated' to handle the new development paradigm. In my experience, you will find this indistinguishable from rewriting your standard for each new development stack. And what about development tool sets? So much productivity enhancement is available by choosing the right component sets and IDE add-ons that you cannot afford to simply skip re-evaluating these choices either, for every project.

Even if you have the budget to rewrite your development process for every new project, or every other new project or every third, do you want to devote a significant amount of your limited resources to producing yet another 'department standard' that you can predict will probably not be usable beyond, at most, a few projects?

There is one other possibility: your current choice for development technology will be durable for, say 5 years, or the velocity of change in development technology will slow. Please write if you find yourself in that position. I would be grateful to hear how you made your choice and how long it lasted. If you keep a development technology stack longer than 5 years, in my humble opinion, your competitors will eat you alive.

So this is the premise, I begin with. To paraphrase Einstein's advice to his son: 'Development is like riding a bicycle. To keep your balance, you must keep moving'.

Developing and casting department development standards as immutable, or changeable only by petition, is a perilous enterprise. What then, is an alternative approach that embraces change in technology? That is the subject of this site.

Thanks for visiting.

Ted Campbell