Found this old, satirical post by Jeffrey Palermo. It reflects one part of a train of thought I have been entertaining over the past couple of months regarding future directions of software development.
I have been trying to resolve two contrasting approaches to development: RAD tools vs. clean code. While there can be some overlap between the terms themselves (both approaches can use code generation for example, but differ in how they use it), I am concentrating on the fundamental difference of approaches.
According to my definitions, RAD tools are tools that focus on quickly, easily and cheaply getting an application together using largely visual tools which generate code or use existing platform code. The “rapid” part of RAD comes from the ease of use of the tool, and the ability to concentrate on high level concerns and abstractions without being bogged down in coding details. A worthy goal :-).
Clean code (a.k.a. ”pragmatic programming”, ”maintainable code” or ”sustainable software”) focuses on creating simple, correct code that is easy to test and maintain. In contrast to RAD tools, the clean code approach focuses on eliminating duplication (not just in the code itself, see the DRY Principle) to achieve rapid progress. The impact of coding details that RAD tools avoid are minimised through reuse and automation (e.g. automating persistence using NHibernate, rather than repeating yourself by continually plumbing your objects into a relational database).
So is one approach generally better than the other? Very rarely is there a silver bullet that will solve all your problems. However, there are sometimes general directions that are positive without being a cure all, perhaps like the development of high level languages like Java and C# helping to prevent wannabe-C++ coders from hanging themselves. So is one of these approaches helpful in a majority of cases? How do you make the choice between the two options?
My main problem when considering this question is that I am biased. I love coding. I love producing a beautifully crafted piece of software that just works (well, I’m pretty sure I’d like it if it happened ;-) ). I can see how beneficial the clean code approach can be in the long term, but I can also see how valuable it is for non-IT colleagues to drag-and-drop a custom report or automate a basic business process as required. Products like SharePoint (a.k.a. MOSS 2007) now make it fairly easy to drag-and-drop an approval workflow for documents, intranet posts etc. So as these tools continue to improve will the benefits of the clean code approach diminish? Will “traditional” coding disappear in favour of RAD tools?
So far my pondering of this has led me to the following ideas, primarily in favour of clean code. First, we have seen this phenomenon before with products like Excel, Access and VB/VBA, which provide a very low technical barrier-to-entry to produce an application that can have enormous business value. This ease of producing applications can cause huge problems when it fails to scale, or a bug that wasn’t hit when the app was used by 3 users causes 50 users to lose data later on. These applications can sometimes end up being reworked or modified by more experienced developers, where layers of hacks and duplication obfuscate the actual logic of the application that is so valuable. How about migrating data to a new back-end or incorporating it in a larger system?
I have a feeling that all RAD tools fundamentally suffer from the same drawbacks as these early RAD tools - tool generated code may work in an original context, but that context is fairly fixed. Try and change it and you end up paying a large amount of technical debt.
What about more visually-oriented designers, like the Workflow Designer in Visual Studio? I really like Jeremy Miller’s take on this (as quoted by Ayende), “Drawing workflow’s with pictures is coding – with every bit of the risk and danger that coding brings”. I have seen this first hand when using a workflow designer (mandated for a project), and then jumping through hoops to get it integrated with an ASP.NET application and an application specific database. For all the ease of dragging and dropping, the effort to turn that into a workable solution was much higher than a clean code approach.
I have also found designers slowly me down in some situations. When you need to have similar actions a designer (well, maybe not a *good* designer) may require you to copy and paste actions and then manually set differing properties. This is a nice way for error to creep in, but also violates the DRY principle that is so important to clean code. For a more obvious example, compare using an application with a mouse versus with a keyboard once you have memorised the shortcuts for your most commonly used features.
How about if we assume you have a “perfect” RAD tool? Fast, easy to use but infinitely flexible? As flexibility increases my unsubstantiated and groundless assumption is that the complexity increases until you have implemented a programming language in itself. Regardless of whether you are dealing with text of boxes and arrows, you are still coding. Use the best method of speeding the process of coding while reducing duplication and repeated effort.
Gee, the way I tell it I’ve almost convinced myself that my future of coding up classes is a given! But realistically there are advantages to a good RAD tool. Ease of use and comprehension is a great advantage to help develop quickly, but you still need a certain amount of knowledge to use it wisely. It really becomes a trade off between how fast you want to go for the basics and how important it is to maintain and extend that base.
I’ve probably rambled more than enough for one post, so I’ll attempt a semi-logical wrap up. RAD tools can be great for a one-shot application, but all end up generating code artefacts of one type or another that are subject to the usual risks of code. You are going fast for a while, but incurring technical debt. The initial investment required to create debt-free, clean code
may slow things down initially, but theoretically should accelerate quickly as repetition is avoided and reuse encouraged. Now just don’t get me started on software factories!
UPDATE 2007-06-04: Phil Haack has a post along the same lines, so apparently I’m in good company :-)
I have been trying to resolve two contrasting approaches to development: RAD tools vs. clean code. While there can be some overlap between the terms themselves (both approaches can use code generation for example, but differ in how they use it), I am concentrating on the fundamental difference of approaches.
According to my definitions, RAD tools are tools that focus on quickly, easily and cheaply getting an application together using largely visual tools which generate code or use existing platform code. The “rapid” part of RAD comes from the ease of use of the tool, and the ability to concentrate on high level concerns and abstractions without being bogged down in coding details. A worthy goal :-).
Clean code (a.k.a. ”pragmatic programming”, ”maintainable code” or ”sustainable software”) focuses on creating simple, correct code that is easy to test and maintain. In contrast to RAD tools, the clean code approach focuses on eliminating duplication (not just in the code itself, see the DRY Principle) to achieve rapid progress. The impact of coding details that RAD tools avoid are minimised through reuse and automation (e.g. automating persistence using NHibernate, rather than repeating yourself by continually plumbing your objects into a relational database).
So is one approach generally better than the other? Very rarely is there a silver bullet that will solve all your problems. However, there are sometimes general directions that are positive without being a cure all, perhaps like the development of high level languages like Java and C# helping to prevent wannabe-C++ coders from hanging themselves. So is one of these approaches helpful in a majority of cases? How do you make the choice between the two options?
My main problem when considering this question is that I am biased. I love coding. I love producing a beautifully crafted piece of software that just works (well, I’m pretty sure I’d like it if it happened ;-) ). I can see how beneficial the clean code approach can be in the long term, but I can also see how valuable it is for non-IT colleagues to drag-and-drop a custom report or automate a basic business process as required. Products like SharePoint (a.k.a. MOSS 2007) now make it fairly easy to drag-and-drop an approval workflow for documents, intranet posts etc. So as these tools continue to improve will the benefits of the clean code approach diminish? Will “traditional” coding disappear in favour of RAD tools?
So far my pondering of this has led me to the following ideas, primarily in favour of clean code. First, we have seen this phenomenon before with products like Excel, Access and VB/VBA, which provide a very low technical barrier-to-entry to produce an application that can have enormous business value. This ease of producing applications can cause huge problems when it fails to scale, or a bug that wasn’t hit when the app was used by 3 users causes 50 users to lose data later on. These applications can sometimes end up being reworked or modified by more experienced developers, where layers of hacks and duplication obfuscate the actual logic of the application that is so valuable. How about migrating data to a new back-end or incorporating it in a larger system?
I have a feeling that all RAD tools fundamentally suffer from the same drawbacks as these early RAD tools - tool generated code may work in an original context, but that context is fairly fixed. Try and change it and you end up paying a large amount of technical debt.
What about more visually-oriented designers, like the Workflow Designer in Visual Studio? I really like Jeremy Miller’s take on this (as quoted by Ayende), “Drawing workflow’s with pictures is coding – with every bit of the risk and danger that coding brings”. I have seen this first hand when using a workflow designer (mandated for a project), and then jumping through hoops to get it integrated with an ASP.NET application and an application specific database. For all the ease of dragging and dropping, the effort to turn that into a workable solution was much higher than a clean code approach.
I have also found designers slowly me down in some situations. When you need to have similar actions a designer (well, maybe not a *good* designer) may require you to copy and paste actions and then manually set differing properties. This is a nice way for error to creep in, but also violates the DRY principle that is so important to clean code. For a more obvious example, compare using an application with a mouse versus with a keyboard once you have memorised the shortcuts for your most commonly used features.
How about if we assume you have a “perfect” RAD tool? Fast, easy to use but infinitely flexible? As flexibility increases my unsubstantiated and groundless assumption is that the complexity increases until you have implemented a programming language in itself. Regardless of whether you are dealing with text of boxes and arrows, you are still coding. Use the best method of speeding the process of coding while reducing duplication and repeated effort.
Gee, the way I tell it I’ve almost convinced myself that my future of coding up classes is a given! But realistically there are advantages to a good RAD tool. Ease of use and comprehension is a great advantage to help develop quickly, but you still need a certain amount of knowledge to use it wisely. It really becomes a trade off between how fast you want to go for the basics and how important it is to maintain and extend that base.
I’ve probably rambled more than enough for one post, so I’ll attempt a semi-logical wrap up. RAD tools can be great for a one-shot application, but all end up generating code artefacts of one type or another that are subject to the usual risks of code. You are going fast for a while, but incurring technical debt. The initial investment required to create debt-free, clean code
may slow things down initially, but theoretically should accelerate quickly as repetition is avoided and reuse encouraged. Now just don’t get me started on software factories!
UPDATE 2007-06-04: Phil Haack has a post along the same lines, so apparently I’m in good company :-)
UPDATE 2007-06-07: Very good company :-)
UPDATE 2007-07-06: David Hayden makes three and a crowd :-)