Wednesday, December 30, 2009

Measure Twice, Cut Once

This is an old proverb that means when we take care to do something in a thoughtful manner, we are less likely to make a mistake that wastes time and materials. It is normally thought of in terms of carpentry, but it can manifest itself in several ways for the software developer.

Measuring twice means taking the time to think through the repercussions of one implementation over another. It means identifying potential areas of weakness in a design that may affect the project’s success. It means making decisions based on your audience, not just the “business unit”.

A practical application of this adage is through the practice of unit testing, specifically writing tests first. Write a failing test (measure once). Then write code to pass that test (measure twice). Thus we have made certain our cuts (refactoring) will match our measurement.

Measure twice and cut once you fully understand the outcome of the decision.

Wednesday, December 23, 2009

I do not think it means what you think it means

I was on a Southwest flight back from Orlando and decided to leaf through their magazine Spirit. In the process, I stumbled upon an article titled “Spirit Lexicon Entry No. 5,972”. I assume this is a recurring one pager that makes an attempt at improving the vocabulary of the business or casual flier. The word in this particular episode was presented as follows:

robust \ro-‘b«Ěst\ adj [From Latin robustus, oaken timber.] 1: Strong, healthy, vigorous. 2: In computer programming, able to perform despite bugs.

I was rather surprised to to see that particular definition used to describe “computer programming” (and yes, it could be read or taken in jest). By definition, code that is buggy is fragile and therefore not robust.

What image is conjured up when someone tacks the moniker robust onto a description of their software? In some cases it probably represents a lack of thesaurus or understanding, but when it comes from another developer what message are they trying to convey? Usually it is quality through words but not necessarily through code. When is the last time you actually referred to your code as robust and weren’t trying to sell something?

Wednesday, December 16, 2009

What is Your Quest?

I was working on a project that involved assessments and evaluations. During the the design phase, it occurred to me that the root of the word question is quest. In mythology and literature, a quest represents the journey towards a goal, or the act of seeking or pursuing something. Therefore, a question is the quest for knowledge and understanding.

As developers, our quest is a perpetual one. This is in part because our environment is in constant flux. The tools available to us are evolving and improving. New techniques, philosophies, and ideas are being debated and incorporated into the collective. Advances in technology have an enormous affect on our profession. In this changing landscape, it is our responsibility to be diligent in the pursuit of knowledge so that we may be participants in the vortex and not passive bystanders surveilling from a distance.

Wednesday, December 9, 2009

Not So Obvious Uses for the Command Pattern

For those not familiar with the Command Pattern, it is what all good design patterns should be - simple, elegant, and powerful.

At its most basic it looks like:

   1: public interface ICommand
   2: {
   3:     void Execute();
   4: }

You can also dress it up a bit to support undo:

   1: public interface ICommand
   2: {
   3:     void Execute();
   4:     void Undo();
   5: }

One of the other variations of the command pattern adds the CanExecute property:

   1: public interface ICommand
   2: {
   3:     void Execute();
   4:     void Undo();
   5:     bool CanExecute { get; }
   6: }

So let’s look at some “not so obvious” uses for this pattern.

Use the command pattern to execute transactions

In this scenario, you would add the commands to be transacted to a queue. When you were ready to perform the transaction, you would iterate the queue calling the Execute method on each command object.

Use the command pattern for exception handling or logging

In this scenario, create a RaiseErrorCommand (or something similar)class. This can be used for failed validation or logging purposes and called from anywhere in the code, including other commands.

Use the command pattern in the UI

Bind toolbar buttons and menu item enabled or visible property directly to command objects that implement CanExecute. When CanExecute changes (evaluates to true or false), the UI will reflect the change.

Use the command pattern for unit or integration testing

This one is very simple and very powerful. Create command classes that implement Undo functionality. Use the command for performing actions to be tested, test the result, and then use the Undo method to restore the system under test and remove the footprint.

Give these ideas a try and have fun with it. Please feel free to share creative ways you may have for using the command pattern.

Friday, December 4, 2009

Big Methods = Better Code Redux

I fear the point of my original post Big Methods = Better Code may not have been properly articulated. This is my attempt re-state the point.

We read books, blogs, magazines, tweets, watch podcasts and videos to help us gather information. It is a part of the learning process. But another part of the process reveals the true value of the data - the act of understanding.

Reading something online or in a book only provides us with a direction or a premise. It is our responsibility as professionals to investigate, analyze, and internalize that knowledge to determine its validity, its merit, and whether it is worth incorporating into our process.

The following proverb typifies this maxim:
I hear and I forget; I see and I remember; I do and I understand.

We can only truly understand something by trying it ourselves.

Wednesday, December 2, 2009

Big Methods = Better Code

I hope most people are cringing at the unmistakable tremor in the force these words invoke (at least for me). A colleague of mine, after a code review, tried to argue that sometimes larger methods are better than smaller focused methods and used Steve McConnell's seminal work Code Complete as evidence to support this claim - specifically section 5.5 “"How Long Can a Routine Be?”.

The studies sighted in this section are at the very least likely out of date. In an effort not to be dismissive, I actually found and read one of the studies. It correlates smaller methods with higher incidents of bugs. Here is an excerpt from the study and the explanation as to why:

“An unexpected trend was observed: Table VII implies that there is a higher error rate in smaller sized modules. Since only the executable lines of code were considered, the larger
modules were not COMMON data files. Also the larger
modules will be shown to be more complex than
smaller modules in the next section. Then how could
this type of result occur?

The most plausible explanation seems to be that the
large number of interface errors spread equally across
all modules is causing a larger number of errors per
1000 executable statements for smaller modules. Some
tentative explanations for this behavior are that: the
majority of the modules examined were small,
causing a biased result; larger modules were coded
with more care than smaller modules because of their
size; and errors in smaller modules were more apparent.
There may still be numerous undetected errors
present within the larger modules since all the "paths"
within the larger modules may not have been fully
exercised
.”

So the results support the premise, but only because the data was flawed.

If you are going to make an argument, articulate it using your own experience and the wisdom of your knowledge. Then you are not just regurgitating something you read in a book or online, but rather demonstrating that you have tested and internalized that information and can make an educated decision on whether it is an approach worth taking and why.

Wednesday, November 25, 2009

Using our common senses

I love to study and learn from other professions. It is a matter of trying to understand their techniques and processes and find ways to incorporate those ideas into my process.

The other night I was watching a cooking competition show, and the chef made a point about using all five senses when cooking. That got me to thinking about how and which senses we use when developing software and writing code.

Sight
This one is the most obvious. You are using it right now to read this blog. This is the sense we use for designing stunning (hopefully) user interfaces and websites, writing our code, watching podcasts and presentations, and writing on our whiteboards. It helps us to choose and set the visual feeling of the IDE themes we choose. This is how we receive most of or knowledge and information about the world.

Sound
Sound comes into play as part of our process in the click-clack of our keyboards, the squeak of the marker on the whiteboard, and the ubiquitous use of headphones to MP3 players and internet radio. Another important aspect of sound in software development is in listening to our clients and team members.

Touch
This one is more a matter of ergonomics than anything else. The difference between the feel of the keyboard at work and at home. The placement of the mouse and keyboard. The feel and contours of the chairs we sit in for hours at a time.

Smell
This one is a little less obvious, but still present. This is the metaphor that illustrates the visceral response to the odor of rotten or rotting code - what we commonly and affectionately refer to as “code smells”.

Taste
This one is the least useful and exercised sense of all for writing code, but it does have it place. Without it, we would not be able to savor the omnipresent caffeine-laced beverages that are the staple of many a developer’s diet.

What are other ways that we can use our sense better or more effectively to help improve the quality of our code?