Back in 1989, when I got my first PC, an 8086, I became obsessed with fractals and more specifically, the famous Mandelbrot set, along with 3D simulated mountainous range. At the time, I was programming using an OOP version of Borland Turbo Pascal and I created multiple DOS applications to generate, visualize, and marvel at those mathematic constructs. I had to take photos of my screen since my dot-matrix printer was not up to the task. When I took the computer science exam as part of the tests to enter the School of Geology, I brought with me pictures and programs on 3″1/2 floppy disks and it helped me get a good grade.
My favorite mathematician, Benoît Mandelbrot died at age 85. He was quite an inspiration and part of the reason why I am doing what I am doing today. In the video below, Professor Mandelbrot, discuss some of his work.
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.
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 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.
For a while now, I have wondered how you can combine Scrum and Kanban. Scrum is a good lightweight method that, if applied properly, can improve productivity, and more importantly, transparency for all stakeholders. On the other hand, Kanban seduced me for its simplicity and its ability to streamline your development. However, I never read anything about combining the two and most articles I have read so far seems to portray those two methodologies as oil and water.
This article take a different approach and shows how a well lubricated and performing Scrum team can benefit from Kanban.
Back in 1989, when I got my first PC, an 8086, I became obsessed with fractals and more specifically, the famous Mandelbrot set, along with 3D simulated mountainous range. At the time, I was programming using an OOP version of Borland Turbo Pascal and I created multiple DOS applications to generate, visualize, and marvel at those mathematic constructs. I had to take photos of my screen since my dot-matrix printer was not up to the task. When I took the computer science exam as part of the tests to enter the School of Geology, I brought with me pictures and programs on 3″1/2 floppy disks and it helped me get a good grade.