So I am a bit more lucid today then I have been the last several. Still a bit sleep lagged but doing a bit better as I have chewed through most of the work I need to do. With that out of the way, lets continue with the Agile Series and dig into Agile Principle 9.
Principle 9: Continuous attention to technical excellence
https://agilemanifesto.org/principles.html
and good design enhances agility.
Agile Principle 9
If you looked at my thought process behind one off in Agile Principle 7, you might think it violates Principle 9. How can it not.
Hey, it’s my job to say that you are violating Principle 9 with Principle 7.
I am going to have to say sorry to Alfred for stepping on his turf. Anyway, no my one off philosophy does not violate Principle 9. If you remember, I said do your best to lay out the program correctly. What we don’t want is someone stopping the advancement of a project to get re-usability that will likely never be used.
It’s like buying a car you are going to drive 100,000 miles. Do you buy the car for $20,000 that will last 175,000 miles or pay $60,000 for the one that will last 250,000?*
*For those who are going to pull out their inner accountant and try to use a cost of ownership calculation. Stop it, this is a mental exercise with only one constraint.
That is the basics of what I advocate. The ability to utilize good technique quickly is in these one off to improve any potential maintenance. Though I have to say in those one off, most I have never needed to go back and perform maintenance.
In longer term projects, use more planning, organization and use Principle 9 to its fullest. These techniques produce better code. You whole goal for you, the developer, is to produce better code today than you produced yesterday. You do that by studying programming and implementing what you learn. It’s learn with every code review. With every conversation you have with your fellow devs, it should be an important part of your life. It is your career.
Fine, whatever, is there anything else you want to rant about on your soapbox?
Alfred is on a roll today. Let continue on and dig a little deeper into Agile Principle 9. There is one very obvious question to ask when you read the principle. Why technical excellence and good design improve agile. Improve the program, yes but improve Agile?
This last point is pretty easy to address. When you combine a good design and good technical skill together, you end up with code that is easy to work with alone or in small groups.
For instance, you are on a team with another devloper. Let’s look at something like the first system I dealt with in my career. It was a employee time system.
If you are working on a feature in the GUI and the logic is in the GUI then everyone will be working in the same GUI. When I change the way button 1 database call is handled while my teammate changes the logic of when button 1 is available, you have the makings for an awful problem.
To anyone who has had to clean up a repository with collisions has probably figured it out. You have two people working on the same code with different tasks simultaneously. This is generally a recipe for a bad day of cleaning up that mess. Not only can the source control have problems but the fixes from programmer 1 could conflict with fixes from programmer 2. It just becomes a nightmare.
It is easier to keep that from happening the more encapsulated the code is. If part A is not mucking up the GUI then it can be worked on without potentially conflicting with the changes being made in the GUI.
Not sure if all that was coherent, but that is my best go at this. As always tell me how wrong I am in the comments below.