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
- July 21, 2010 ( 2 comments )
- Rants
I am told that some developers don’t like coding standards imposed on them. I do not have that experience. In working with thousands of developers I notice that they prefer following standards as long as it supports them in doing a good job.
We all hate busy work or pointless activities. If your coding standard is to have a comment for every line of code, like it was for me when I worked at IBM 20 years ago then developers may not follow it because it is _stupid_.
But coding standards that support the team are often quickly assimilated if all the team members see the benefit. However, we may not see the benefit because it wasn’t described to us correctly. For example, one of the most valuable practices I teach is encapsulation of construction. Most developers are familiar with the concept but perhaps never saw the benefit of using it because it wasn’t explained to them well.
It seems like every time you turn around someone has a new tool or methodology or something that is supposed to revolutionize our industry. No wonder seasoned software developers have become jaded. We often find what works for us and stick to it. We resist the flavor-of-the-month methodology because we’ve seen too many come and go.
But since we work in such a fast changing industry we have to reevaluate our knowledge on occasion so we continue to learn new things. This is true for other fields as well. Most M.D.’s spend at least 12 hours per week reading journals. Even CPA’s are required to get several days of training each year in order to renew their license. We developers have to be even more vigilant.
{2 Comments }
Previous Post: « Compromises on Quality
Next Post: To Be Agile (Techniques of Design) now offers Certified Scrum Developer training! »
Well said David – and too true unfortunately about becoming jaded due to the onslaught of new tools/methodologies/frameworks/…
I came across your site from a local company (Comsys) rep that I believe attempts to connect training services like yours to the area… it seems TOD is really offering a lot of Scrum training; the rep had submitted to me the outline about Agile S/D Essentials. The team I work with doesn’t agile at all, but I’m sure some aspects would fit … any thoughts/recommendations for your training courses?
Yes, the engineering practices that I teach in my Agile and Scrum developer classes are applicable to all software development methodologies. Even in waterfall we still need to build high quality software that can easily change, which is what the techniques that I teach help with. It is just that on agile projects we must be even more vigilant to make sure our code doesn’t degrade. I would say these engineering practices are critical on Agile projects and still very important on non-Agile projects.