I spend a good amount of time thinking of ways to be a better programmer.
Having been an Agile Coach, I’ve seen how changes in thinking can lead to more reliable programs that are more likely to meet customer needs. However, I think that Agile is not the final solution.
There’s always a better way.
Having spent time learning about lean manufacturing in physical production, there are some common tactics of agile that I think aren’t solving the ‘real’ problem.
Take test-driven development. Part of the purpose of it is to use it to lead to the simplest design. However, it’s also considered a form of constant QA – if you make a breaking change, you’re quickly alerted.
Translating this to lean manufacturing, it’s like adding a huge number of QA steps, everywhere along your process. Sure, you’d spot problems early. However, you’d also drastically decrease your throughput.
Instead of adding all those QA steps, with lean principles, you’d find ways to prevent something from ever being built wrong.
That’s what I’m trying to find in my experiments with Self Aware Objects. With the current code, instead of writing a bunch of validation code in all my controllers, I can add some declarative attributes to my properties and have the object validate itself.
Moving this validation code out of the controllers, and into the business classes, does several things:
- Eliminates errors that would occur when manually writing validation routines.
- It’s easier to pass along business knowledge needed for future changes, due to rules being in a consistent, obvious location.
- Allows for object validation to occur anywhere. You can easily have your data persistence layer throw an exception if the program attempts to save an object with bad, or missing, data.
Most of my work has been in custom programs written for businesses. So that’s what I’m looking to improve.
The experiments I’m working on are not for every type of application. However, I think that we can find a better way to develop programs, which will let us automate and improve more business processes – the real reason why we write programs.