Automating unit testing is difficult but that’s no excuse
In this short article Rob Diana argues that developers are responsible for producing working code and that to do so, it is imperative that the code gets tested and exercised through unit tests.
This is perfectly reasonable and most developers I worked with don't have any issue with unit testing as defined by Wikipedia as long as the level of automation is low or non-existent. The Wikipedia article on unit testing explains that "[unit testing] implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation."
However, a major gap exists between exercising the code through manual or semi-automatic tests and writing automatic tests to verify continuous integration builds. Of course the latter produce higher quality software in the long run but this gap prevents some teams from reaching a higher level of code quality while minimizing rework (i.e. higher productivity).
Implementing automated unit tests is not simply a technical exercise. It is also a complex problem that requires a sophisticated and coordinated effort among developers accompanied by a culture change where developers and other stakeholders:
- treat unit testing code with the same level of respect as the rest of the application (this code may not end up on the server or the user's desk put it is an essential element in minimizing defect escape rate);
- accept that an automated build is successful, if and only if, all the associated unit tests passed.
This combination of cultural and technical changes is essential to a successful and full-scale automated unit testing implementation.
Things to think about before and after a daily stand-up meeting
Daily stand-up meetings are at the core of the Scrum process. They help synchronize the team and quickly escalate impediments. Regardless if you have been participating in those meetings for years or you are just starting today, Mike Griffiths just published two useful posts to help us get more out of this critical activity:
Anchoring Effect
According to wikipedia:
Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.
This is a dangerous bias that can bite you when you are estimating tasks or stories in an Agile environment. I am even wondering if this plays a role when you are poker planning, and how much this influences your decisions from the get go.
Anyway, this article goes into detailing the anchoring effect and the "You are not so smart" blog is providing insights on common human behavior that plays an important role in software development.
While the phenomenon is well-known, I am wondering what a team can do about it. How can you overcome its nefarious effect and also how do you measure its effect in the long run.
[via You are not so smart]
Original photo by Plbmak
Agile Anti-Patterns
I believe that Agile is a great tool to help development teams achieve more, improve, and reach their next level in effectiveness, productivity, or creativity. However, like any tool, it can be misused or misapplied. You can shoot yourself in the foot if you are not applying a certain level of discipline or hygiene.
Mike Griffiths posted a short and sweet article on this subject that he entitled Agile anti-patterns. He classifies those anti-patterns as follow:
- Agile as a silver bullet
- Agile as an excuse for no discipline
- Agile without explanation
- Shallow Feedback
A crash course in modern hardware
If you have not reviewed lately how modern CPUs operate and how they differs from CPUs that you grew up with, you may want to watch this video. It is quite long but certainly instructive.
You will learn about what impacts performance today and how Donald Knuth was right all along. :-)
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" — Donald Knuth