david.segonds.org » Work

Automating unit testing is difficult but that’s no excuse

David — Sat, 14 Aug 2010 14:05:57 +0000

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.

Unit Testing as the Last Resort for Code Verification?

Things to think about before and after a daily stand-up meeting

David — Tue, 10 Aug 2010 12:28:29 +0000

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

David — Sat, 31 Jul 2010 01:23:29 +0000

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

A Pattern for Using Scrum and Kanban

David — Fri, 30 Jul 2010 01:17:11 +0000

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.

This is food for thought.

[via AvailAgility]

The Cloud is Cheaper than Bare Metal

David — Thu, 29 Jul 2010 03:02:49 +0000

Well, I don't know about yours but many organizations are looking into the Cloud at large to lower their cost and increase reliability. Looking at Amazon EC2, prices seem expensive when you are on a tight budget, especially if you belong to a small organization.

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.

Adapting Steven Covey’s concept to retrospectives

David — Wed, 28 Jul 2010 01:16:17 +0000

In Seven Habits of Highly Effective People, Steven Covey describes the concept of circles of control, influence, and concern. Succinctly, this concept states that you should only focus on the few things you can control and influence, and not on the many for which you are powerless.

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]

On the road to Competence

David — Sun, 25 Jul 2010 02:27:58 +0000

How can one improve competency in a software development team? This is a critical question for a software development manager and this video of a presentation given by Jurgen Appelo at the 2010 Norvegian Development Conference provide an insight that attempt to answer this question.

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

Agile Anti-Patterns

David — Sat, 24 Jul 2010 18:40:41 +0000

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

Drilling for oil

David — Fri, 23 Jul 2010 01:31:19 +0000

With the Deepwater Horizon incident in the Gulf of Mexico, there never was that much interest from the public on how a well is being drilled in over 5,000 feet of water. The video below is a presentation given by some colleagues from Shell at the Aspen Ideas Festival.

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.

The surprising truth about what motivates us

David — Sun, 06 Jun 2010 22:52:21 +0000

You may have seen the video below as it was quite popular in the last few weeks. If not, I really encourage you to watch it as it is food for thought if you hold a job where you have to manage other individuals.

www.youtube.com/watch?v=u6XAPnuFjJc

Agile vs. Waterfall: A Tale of Two Teams

Linkedin Etiquette

David — Tue, 06 Apr 2010 22:53:27 +0000

Linkedin is a marvelous tool for professionals. This is nothing new and given my limited readership, we probably are connected via Linkedin already.

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

Don't collect connections
Only Connect with people you discussed or corresponded with and whom you feel are professionals
Connect with co-workers and former colleagues
Ignore invites from people you don't know
Import your list of contacts to reconnect with former business partners
Recommend former colleagues but not current colleagues
Rarely ask for a recommendation and only if you already gave one some time before
Use a personal e-mail address for logging in, not a work e-mail address
Register any new e-mail address that you expect people to use now or in the future
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.

A crash course in modern hardware

David — Thu, 28 Jan 2010 18:34:48 +0000

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

No related posts.

James Bach is offering free testing lessons over Skype

David — Sun, 06 Dec 2009 04:50:12 +0000

James Bach is proposing to tutor testers via Skype for free. This is a very interesting concept and this is the first time I hear about such an experiment. I wish him success and I am looking forward to see how this develops.

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

No related posts.

Frequently Forgotten Fundamental Facts about Software Engineering

David — Sat, 05 Dec 2009 14:45:03 +0000

In this article, Robert L. Glass, list principles, facts related to software engineering. The list is organized onto the following categories:

Complexity
People
Tools and Techniques
Quality
Reliability
Efficiency
Maintenance
Requirements and design
Reviews and inspections
Reuse
Estimation
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]

Secret Perl Operators

David — Wed, 02 Dec 2009 03:51:55 +0000

I don't know about you, but I feel that Perl is a great scripting language. I have used it quite a bit in the past and it always helped me accomplish what I wanted to accomplish. I must also admit that Python now has my favor and one of the reason is the simpler syntax and object manipulation.

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.

Programming Puzzle

David — Fri, 27 Nov 2009 07:53:52 +0000

Tonight, I found a programming puzzle while reading the blog "It's common sense, stupid". I solved the puzzle, but I don't know what to do next. Do you know what I am supposed to do once the puzzle is solved?

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.

If You Want Something Done, Practice Your Patience

David — Wed, 25 Nov 2009 15:30:56 +0000

As a manager you've been taught, either by your peers, or through hard knocks, to avoid micromanaging your teams. You quickly learn that micromanagement only alienate people.

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.

Patterns and Practices for Distributed Teams

David — Tue, 24 Nov 2009 15:30:23 +0000

If you are working with teams distributed across multiple timezones, you know how difficult it can be to operate efficiently at times. Over the years, you surely have experimented and tried out different patterns or processes that work in your context.

I have been working for ten years with teams that were in timezones seven to thirteen hours away from my own and we have experimented quite a bit. This is fun and frustrating at the same time.

J.D. Meiers exposes some patterns and practices that will work with distributed teams. I have found that those patterns are not appropriate in every circumstances but they are an excellent summary that will prevent you from reinventing the wheel

[via J.D. Meier's Blog]

Original photo by extranoise and published under an Creative Commons Attribution License

Pranav Mistry: The thrilling potential of SixthSense technology

David — Tue, 24 Nov 2009 02:41:48 +0000

Get rid of your keyboard, screen, and mouse. Project an interface wherever you wish and interact with the Digital world in new ways. There are some of the things Pranav Mistry is describing in the video embedded below.

How fast do you think we will reach a point when the user interface we are accustomed two will be fully replaced by a new paradigm?

[via Kallokain]

No related posts.

Skepticism in Software Development

David — Sun, 15 Nov 2009 20:31:20 +0000

I just read an article from Jason Gorman, from Parlez|UML, on skepticism in software development. He explains that a lot of preconceived theories about software development abound but few of those theories have been thoroughly investigated and therefore, it is difficult to know if they bring value to the engineering process or not. For example, Jason mentions refactoring that claims to make changes easier without supporting research.

In my understanding, this leads to more academic research on those theories to validate them and also to explore their practical boundaries and limits. I believe that this is a perfectly valid, and necessary approach.

However, in parallel to this academic approach, I would have a tendency to take a more pragmatic route. If a concept like refactoring comes to my attention, I would try it out in my environment, see if it has value to my organization and decide, after retrospective, to continue using the method or not. Also, you can not detach the software engineering method or principle from the human component. The method, under properly applied leadership, has to be accepted and embraced by the programmers, testers, or UX designers that would use it. Therefore, the development team, including its lead, decides, if a particular theory helps bring more value to customers.

[via Parlez|UML]