2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 21, 2018
- Rants
Ok, I admit it. I am lazy.
But laziness can be a virtue. I think it is humanity’s basic laziness that let us create computers in the first place. Computers take the drudge-work out of many tasks.
My basic laziness has motivated me to find better ways to build software because I simply got tired of maintaining poor code.
Over the years I started to get a feel for what kinds of enhancements were difficult to make in a system and why. It turned out that I would see the same patterns over and over again play out in each of the code bases of my clients.
Systems were frail and difficult to change. When developers tried to make a change or add a feature to their system it would become unstable.
Physicians use the term pathology to describe the symptoms of a particular disease. Poor code can also be seen in terms of pathologies but they are not caused by a disease, they are caused by one or more code qualities that are missing.
So what is code quality? It’s easy to identify quality in material goods or services but quality in software is more difficult to define. Some say the quality of software is meaningless because the user has no direct experience of it.
I beg to differ.
Users of software systems may not see the code but they definitely experience it. Even if the feature performs well initially, it may need to be modified or enhanced later and the ability to do this easily and without breaking other parts of the system directly relates to code quality.
I usually talk about six key qualities that code should have or be: cohesive, non-redundant, encapsulated, assertive, testable, and explicit. I see them as facets of the same gem. One leads to another so even if you only focus on one or two you are bound to get improvements in all of them.
Kent Beck tends to focus on eliminating redundancy and in doing so tends to improve the overall design of his code. I like cohesion because I find that if I can name something well it is usually cohesive. Different people gravitate to different code qualities.
You don’t have to focus on all of them. Pick one or two that make sense to you and focus on those. When you improve one and you see the other code qualities improve then you know you’re on the right track.
I don’t consider laziness as a quality but maybe as a motivator. I’ve found ways to automate redundant or repetitive tasks because I’m lazy. I hate redundancy in my code so you know I especially hate redundancy in my life. If I have to go back to the store because I forgot to buy something I needed—I hate that. So, I try to find ways of streamlining the work that I do so that I’m automating the rote tasks and focusing on doing the creative stuff.
Previous Post: « Rebuild or Refactor
Next Post: Object Thinking »