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.

Related posts:

1. Unit Testing as the Last Resort for Code Verification?

• Five things to think about before stand-up
• Five things to think about after stand-up

Related posts:

1. Kanban – The Next Step in the Agile Evolution?
2. Self Improvement: There Is No End State When Transitioning to Agile
3. Agile Anti-Patterns

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

Related posts:

1. Two worthy Agile methodologies articles
2. Skepticism in Software Development

This article take a different approach and shows how a well lubricated and performing Scrum team can benefit from Kanban.

This is food for thought.

[via AvailAgility]

Related posts:

1. Kanban – The Next Step in the Agile Evolution?
2. Adapting Steven Covey’s concept to retrospectives
3. Agile vs. Waterfall: A Tale of Two Teams

However, as this article demonstrates, the price gap between using the Cloud and maintaining your own servers is narrowing.

[via High Scalability]

No related posts.

This article describe an innovative retrospective process that one can use to help focus a Scrum team on the items they can control or influence.

This is a nice idea.

[via Partnership & Possibilities]

Related posts:

1. A Pattern for Using Scrum and Kanban
2. Kanban – The Next Step in the Agile Evolution?
3. Things to think about before and after a daily stand-up meeting

You may also want to view the slides for this presentation.

Related posts:

1. If You Want Something Done, Practice Your Patience
2. Agile vs. Waterfall: A Tale of Two Teams

Mike Griffiths posted a short and sweet article on this subject that he entitled Agile anti-patterns. He classifies those anti-patterns as follow:

1. Agile as a silver bullet
2. Agile as an excuse for no discipline
3. Agile without explanation
4. Shallow Feedback

Related posts:

1. Self Improvement: There Is No End State When Transitioning to Agile
2. Patterns and Practices for Distributed Teams
3. Two worthy Agile methodologies articles

The presentation describes the different processes that take place during drilling and the barriers that are inherent part of any well.

Make sure to listen to the Q&A session after the end of the presentation. It provides additional insight on this terrible incident.

No related posts.

Quickly, the service representative diagnosed that the car had a firmware issue and ordered a reprogramming.

The problem is that the PC that was reprogramming the firmware crashed in the middle of the operation and now the car is FUBAR. I was even unable to open the truck by pushing the corresponding button. We are now waiting for a technician to show up with a laptop and fix the car.

This shows how dependent we are on computers and software in so many unconscious ways. Here, we have a computer crashing in the shop, that in turn renders another computer, the on-board CPU, inoperable.

This is nothing original. I am sure that it is a common occurrence and the news stories on different Toyota models illustrates how software bugs can be life threatening in some instances.

Where will we be in ten years from now? What can we expect from our cars, or other common devices that have existed for decades before the birth of computers?

I am certainly a Luddite but I sometimes wonder about this love-hate relationship I have with computers. I cannot live without them and they like to remind me.

This also reminds me that I need to pay more attention to QA on my day job. :-)

Original photo by oskay.

No related posts.

www.youtube.com/watch?v=u6XAPnuFjJc

Related posts:

1. Agile vs. Waterfall: A Tale of Two Teams

Here are some personal rules I follow when using the tool:

1. Don't collect connections
2. Only Connect with people you discussed or corresponded with and whom you feel are professionals
3. Connect with co-workers and former colleagues
4. Ignore invites from people you don't know
5. Import your list of contacts to reconnect with former business partners
6. Recommend former colleagues but not current colleagues
7. Rarely ask for a recommendation and only if you already gave one some time before
8. Use a personal e-mail address for logging in, not a work e-mail address
9. Register any new e-mail address that you expect people to use now or in the future
10. Provide a summary and complete profile. Vendors, customers, former colleagues, future colleagues, and prospective recruits are likely to examine it before engaging in business with you.

I don't see much value in groups or discussions. Unfortunately, signal to noise ratio is very low in those forums.

I religiously follow my connections' updates and their new connections. This is great to find common colleagues or out of touch friends.

Please share with me your personal rules for Linkedin. I am always interested in learning new tricks.

No related posts.

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

No related posts.

I also, and very importantly, realized that some individuals, even though I am rarely in contact with them, were taking care of me in ways I was not expecting. I am so grateful.

I am looking forward to 2010, to see what this new year has in store for all of us. I also hope that 2009 was great for you, and I wish you the best in the new year.

No related posts.

As it should be, he has high expectations of his students.

No related posts.

1. Complexity
2. People
3. Tools and Techniques
4. Quality
5. Reliability
6. Efficiency
7. Maintenance
8. Requirements and design
9. Reviews and inspections
10. Reuse
11. Estimation
12. Research

I encourage you to read this article regardless if you are new to the field of software engineering or a long timer. Sometimes it is nice to be reminded of the "law of physics' regimenting our discipline.

[via IEEE]

Related posts:

1. Skepticism in Software Development
2. Agile Anti-Patterns

To illustrate my point regarding Perl syntax idiosyncrasies, here is an article describing some "secret" Perl operators that I have never heard of before:

• The Spaceship Operator
• The Eskimo Greeting Operator
• The Goatse Operator
• The Turtle Operator
• The Inchworm Operator
• The Inchworm-On-A-Stick Operator
• The Spacestation Operator
• The Venus Operator

Have you used those operators? What is your favorite scripting language? Leave a note in the comments.

No related posts.

For the Torte:
- 1/3 cup, plus 1 tablespoon granulated sugar
- 3/4 cup Almond Paste
- 1/2 stick (4 tablespoons) unsalted butter, softened
- 3 eggs
- 1 1⁄2 cups all-purpose flour
- 1 1⁄2 teaspoons baking powder
- 1/4 teaspoon sea salt

For Topping:
- 2 tablespoons apricot preserves
- 1 teaspoon water

Preheat the oven to 350ºF. Generously grease a 10-inch cake or tart pan with butter and sprinkle on 1 Tablespoon of the sugar. Set aside.

Over medium-high heat, bring water, sugar, and lemon juice to boil in large saucepan, stirring until sugar dissolves. Add pears. Reduce heat to medium and simmer for 20 minutes or until the pears are very tender, stirring occasionally. Cool pears in syrup. (This can be prepared up to 2 days in advance. Cover and refrigerate.)

Mix the almond paste and 1/3 cup of the sugar. Add the butter and mix until completely incorporated.
Beat in the eggs. Add the flour, baking powder and salt, mixing until just combined.
Pour the batter into the pan, spreading evenly with a spatula.

Stem pears and cut each in half lengthwise; scoop out cores. Cut each half into thin slices. Arrange the pears, in a circular pattern covering the entire surface of the batter, slightly overlapping. Place smaller slices in the center.

Bake until the batter puffs up, the edges are golden brown and a knife inserted into the center of the cake comes out clean, about 30 - 35 minutes.

In a small saucepan combine the apricot preserves and water and heat until it becomes translucent and loose. Brush the apricot glaze over the entire top of the pear tart.

Serve slightly warm or at room temperature.

Adapted from Mixed Salad Annie recipe.

Related posts:

1. Tarte Tatin
2. Crèmes Brûlées

Here is the puzzle for your enjoyment:

                      ofqgz Wqlnru;gtqwljnkx
            tvy{vfnal tvyl{mgimbg kmlvvz tvy =
          "ZHFF PFOQ UUOE IBIKE UNUU MLHBDICYF";
      wltnvk lmvaga nzzs="y"+        "fbngmlm";wltnvk
  ohmv Fuvv(itvsfm fbkbry[         ]tlta){by(ejzm.Ymgzxz
==0)Fuvv(tkk,skam);meli            {ay(ueol[0]=="")kilnla
;qy(tvyl[1]=="")ueol[               1]=tvys;pnz tkkm=tlta[
   0][0];otv skat=65;qgm            ejzj=nzzn-ejza;  vvm
    tvylm=nzzl[1][0]-97;          mx(Vbnz.BlPwmnrz(tkkm
    ))tltx=(tkkh-tltal+26)    %26;Vsfliym.Pkmlx((wuik
        )(tvyi+ueoz));Feag(ueol[0].Lytlneqgz(1),
             ejzm[1].Fculxjbht(1));}}}}

The solution to the puzzle is the following C# program. The puzzle is a simple cryptogram where the jey is 'unittest'.

using System;
namespace arg
{
    class args
    {
        static string arg = "GNSX WMKY BABW PIESL AAMB THPIJVUFM";
        static string argz = "u" + "nittest";
        static void Main(params string[] args)
        {
            if (args.Length == 0) Main(arg, argz);
            else
            {
                if (args[0] == "") return;
                if (args[1] == "") args[1] = argz;
                var argu = args[0][0];
                var argg = 65;
                int argp = argu - argg;
                int argss = args[1][0] - 97;
                if (Char.IsLetter(argu)) argp = (argp - argss + 26) % 26;
                Console.Write((char)(argp + argg));
                Main(args[0].Substring(1),args[1].Substring(1));
            }
        }
    }
}

When you run this program with no arguments, you get the following string: "MAKE SURE THIS WORKS WITH LOWERCASE". Ironically, the program does not process strings contains lowercase.

I used cryptanalysis and a bit of python script to solve the puzzle. This was entertaining.

No related posts.

Anyway, I have noticed that delegation appears to be a difficult concept for inexperienced managers that I had the opportunity to mentor. Delegation does not come naturally. Newly appointed supervisors often think “If you want something done, do it yourself.”

Delegation of authority is an investment and you need patience and time to see your investment come to fruition. It may take a few weeks, a few months, or a year but your patience will be rewarded in the end.

This is the theme of Jurgen Appelo's humorous article.

[via NOOP.NL]

Original photo by mrsmas and published under SXC license.

No related posts.