2025 Public Training Schedule
January 14 – 17, 2025 – 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
- March 10, 2010
- Rants
I have a friend who is a hardware engineer. He says he hates software because it is too forgiving. When he designs electronics he has to follow strict engineering practices. One little mistake will likely make his whole design fail and cost his company over a $250,000 to “re-fab” the chip. He has to be extremely careful when he design circuitry.
But we software developers can get away with a lot. If our code is a little disorganized or a quality is missing here or there it will still run and so we often don’t worry about these things until it is too late. Cumulative errors can end up making it very difficult to change a system and at some point we end up with spaghetti code.
The best software developers that I know build all their software to be maintainable; they always follow engineering practices that work for them because it is their habits. Like a doctor who washes her hands before seeing each patient, we developers must have a set of engineering practices that we apply all the time.
If you ever go in for surgery and you see the doctor skip washing their hands then I suggest you get up and leave immediately. The same is true for developers. If you see a developer who doesn’t believe in coding standards or only does them some of the time then I suggest that you consider the impact of their choices.
Software engineers need a set of practices they can rely on. When we make these practices our habits it means we no longer have to question ourselves. Questioning ourselves is a good thing but not all the time. I never questions if I should seeking to make my classes cohesive, I always do because I know that cohesive code have a lot of value.
Sometimes people say to me they don’t have time to worry about code quality when management is breathing down their neck to get a feature out the door. Yes, we must make compromises and rarely can we achieve perfection in all that we do but it is also up to us as developers to make the case for quality because we are the experts in this area. Management might not understand the implications of cutting some corners.
Previous Post: « The Habit of Quality
Next Post: Dolphins and Developers »