www.hans-eric.com

This is a guest post by Janet J. Fleming.

Are You Going to Get Benefits from a Software Program Testing Job?
 
This is a good question….initially you must see if you have a certain type of personality to accomplish software testing. You ought to be organized, logical and thorough. You will be writing test cases depending on business and functional requirements – or in other words you should do. 
 
Then you’ve to implement those tests – often repeatedly. Your primary goal is always to be sure that no software goes out to your customer without all the bugs found. It’s rarely achievable, but should be your main goal. I always prefer to believe that your 2nd goal must be to have every developer hate you because you keep finding bugs inside their code 🙂
 
The answer if software testing is an excellent career option is dependent upon who’s asking the question. I’ll answer it as if my audience is definitely an engineer.
 
I’m flip, but sincere – my working practical experience has proven to me that the theory of software development never comes about in reality.
 
Theoretically, software testing is:
– Validating and recording that software program performs the functions it’s supposed to.
– Making sure and recording it doesn’t do anything whatsoever it is not designed to
 
This presupposes you have been told what it is supposed and not supposed to do. People you’re working for don’t always do this – they might not necessarily rely on you not to run away with their secrets.
 
Because software program is a business (except when you are doing work for the military) business guidelines apply a lot more strongly than engineering principles. Software testing is expensive, and so the decisions about goals and how much to do can be extremely based on ROI considerations.
 
Inside the end-user relationship, the user’s perception just isn’t necessarily directly related to the physical world, and it’s also the user’s perception of whether your system works that finally rules inside the minds of management, whose job is purely to ensure no one is complaining concerning the software.
 
Therefore, the truly practical explanation of software testing could be summarized as 3 goals:
 
1° Verify the people that use software believes it’s doing whatever they require it to accomplish
 
2° Verify that this software doesn’t do anything immediately detectable that is not desirable for the user.
 
3° Verify that any undesirable action has a sufficient length period that the software will look to perform properly long enough for you to make it to another round of VC investment or sell the business 🙂 
 
And you? Do you consider Software Testing could be the right career path?

Who am I ?: Janet J. Fleming is writing for the software testing course online blog, her personal and non-commercial in nature hobby web site to offer free strategies for software testing novices/specialists to help them get a new work.

I have enjoyed a two day Certified Scrum Master course with Chet Hendrickson and Henrik Kniberg as teachers. A big part of the course was dedicated to questions and answers (implemented as a Scrum exercise) and lots of interesting subjects were elaborated upon by Chet and Henrik. I figured I’d document some of them on this blog, starting with this question:

“Should Scrum Masters code?”

Both Henrik and Chet agreed that the Scrum Master role may or may not be a full time job depending on several circumstances like team size, the maturity (in Scrum a sense) of the team, etc. In fact, a Scrum Master should strive for making her role redundant.

The Scrum Master is needed the most in the beginning, but once the worst impediments are removed and the team gets more comfortable with the process, the role becomes less important. At that point, the Scrum Master work load becomes unevenly distributed, and tends to be concentrated towards the beginning and end of the sprints. When that happens, you have basically two options:

Alternative 1: Make the Scrum Master role for this team a part time assignment.

Alternative 2: Keep the full time Scrum Master but have her or him participate in development activities when there’s time for that.

Of these two, the second one is much preferred, mostly because a “drop-in” Scrum Master will be less effective in discovering and removing impediments. So, in that perspective having a Scrum Master that is cross-functional seems like a good idea.

When I was young…er a friend of mine barged into a role playing session (Yes I was a nerd. Am.) with the following question: “Do you notice anything different about me?” He had his newly acquired driver’s license taped to his forehead…

I would do something similar now to mark an equally great change in my life, but  I haven’t figured out how to make my newly acquired employment stick to my forehead. So, here it is instead, in plain text:

I have gotten myself into consulting.

My new employer is Know IT, a fast growing Swedish IT company mainly targeting the Scandinavian IT sector.

I’m quite happy with the change. Although I enjoyed the seven years with my previous employer very much, I hope the new position will bring me diversity and professional growth.

If you’re thinking about changing your own work situation, but haven’t found the guts to do so, then I can recommend reading the inspiring post by Justin Etheredge. He, obviously a couple years ahead of me, quit consulting and started his own company. I can totally relate to that. But one step at a time, right?

Cheers!

A year ago I began the process of replacing my Palm Treo with something, well, not so ancient. The choice was simple, then. Palm had just released Palm Pre, with a brand new operating system that breathed innovation and promised the best developer experience.

The phone hadn’t been released in Sweden (or Europe) yet so I waited. And waited. Then Palm got financial troubles and was sold to HP, while I – loosing faith – entered into a state of irresolution.

That was until a friend of mine showed me an app he purchased for his iPhone. It enabled him to point his device towards the night sky and get information of the stars and planets in view. Fantastic. Breathtaking. I had to get myself an iPhone.

Of course, that was before Chad Fowler moved to Android. Now what am I to do? I guess I should try and make an informed decision.

The requirements:

• UMTS capable
• Starmap or equivalent application
• Fun to develop for

iPhone seems to have the best user experience, and integrates beautifully with other devices from apple. On the flip side is the vendor lock-in.

Android has Google Sky Map, not as good looking as Starmap on iPhone but the important  functionality seems to be there.

Developing for Android gives you several alternatives. iPhone, on the other hand, has only one allowed option. I can’t decide if having to learn Objective-C should be considered an advantage or disadvantage for iPhone.

I can’t seem to make up my mind between iPhone and Android. I’ll probably end up flipping a coin, so any input that can help me choose is much appreciated.

Cheers!

Martin Fowler has an interesting post up called Utility vs Strategic Dichotomy. The point he’s making is that there are essentially two kinds of software projects, which he names utility and strategic, and that they need to be treated entirely different in the way you staff and run them.

Utility projects, he defines, are the ones that provide functions that are often necessary and crucial to run the business, but not a differentiating factor in competition with other companies.

A classic example of a utility IT project is payroll, everyone needs it, but it’s something that most people want to ‘just work’

Then he delivers hammer blow number one.

“Another consequence is that only a few projects are strategic. The 80/20 rule applies, except it may be more like 95/5.”

What Martin Fowler is saying is that a vast majority of us are doing work that is of no strategic importance to the business we support. I’m sure this statement cuts a wound in many developer’s and project manager’s self images, mine included. But I’m with Martin on this one. It’s time our sector gets its feet back on the ground and we start to realize that we’re here to support the business. Not the other way around.

Hammer blow number two.

Another way the dichotomy makes its influence felt is the role of agile methods. Most agilists tend to come from a strategic mindset, and the flexibility and rapid time-to-market that characterizes agile is crucial for strategic projects. For utility projects, however, the advantages of agile don’t matter that much.

I have a little harder swallowing this one. That the agile movement doesn’t “matter that much” while developing utility systems doesn’t ring true to me. Yes, time to customer is not as critical as in strategic projects, but that doesn’t mean that building the right system isn’t important to utility projects as well. And the agile values will help reducing cost and risk in any project, be it utility or strategic.

Cheers!

The short version of this post:

Do not spread generic types around. They are ugly and primitive.

Allow me to elaborate.

Generics are great

Before we got Generics (2004 in Java, 2005 in C#, and 2009 in Delphi) the way to enforce type safety on a collection type was to encapsulate it and use delegation.

class OrderList
{
private ArrayList items = new ArrayList();

public void Add(OrderItem item)
{
items.Add(item);
}

// Plus lots of more delegation code
// to implement Remove, foreach, etc.
}

Nowadays, we can construct our own type safe collection types with a single line of code.

List<orderitem> orders = new List<orderitem>();

That alone is good reason to love generics, and there lies the problem; many developers have come to love their generics a little too much.

Generics are ugly

The expressiveness of generics comes at a price, the price of syntactic noise. That’s natural. We must specify the parameterized types somehow, and the current syntax for doing so is probably as good as anything else.

Still, my feeling when I look at code with generics is that the constructed types don’t harmonize with the rest of the language. They kind of stand out, and are slightly negative for code readability.

OrderList orders = new OrderList();
// as compared to
List<OrderItem> orders = new List<OrderItem>();

This might not be so bad, but when we start to pass the constructed types around they become more and more like litter.

List<OrderItem> FetchOrders()
{
//…
}

double CalculateTotalSum(List<OrderItem> orders)
{
//…
}

void PrintOrders(List<OrderItem> orders)
{
//…
}

Besides being noisy, the constructed types expose implementation decisions. In our case the list of orders is implemented as a straight list. What if we found out that using a hash table implementation for performance reasons would be better? Then we’d have to change the declaration in all those places.

Dictionary<OrderItem, OrderItem> FetchOrders()
{
//…
}

double CalculateTotalSum(Dictionary<OrderItem, OrderItem> orders)
{
//…
}

void PrintOrders(Dictionary<OrderItem, OrderItem> orders)
{
//…
}

Comments redundant.

Generics are primitive

A related problem is that the constructed generic types encourage design that is more procedural than object-oriented. As an example, consider the CalculateTotalSum method again.

double CalculateTotalSum(List<OrderItem> orders)
{
//…
}

Clearly, this method belongs in the List<OrderItem> type. Ideally, we should be able to invoke it using the dot operator.

orders.TotalSum();
// instead of
CalculateTotalSum(orders);

But we cannot make that refactoring. We cannot add a TotalSum method to the List<OrderItem> type. (Well maybe we can if we make it an extension method, but I wouldn’t go there.) In that sense, constructed generic types are primitive types, closed and out of our control.

So we should hide them

Don’t get me wrong. I use generics a lot. But for the previously given reasons I do my best to hide them. I do that using the same encapsulation technique as before, or – at the very least – by inheriting the constructed types.

class OrderList : List<OrderItem>
{
  double TotalSum()
  {
    //…
  }
}

So, the rule I go by to mitigate the downsides of generics, is this:

Constructed types should always stay encapsulated. Never let them leak through any abstraction layers, be it methods, interfaces or cl

That is my view on Generics. What is yours?

Cheers!

P.S.

Just to be clear, the beef I have with Generics is with constructed types alone. I have nothing against using open generic types in public interfaces, although that is more likely to be a tool of library and framework developers.

You may have heard of The Boy Scout Rule. (I hadn’t until I watched a recorded presentation by “Uncle Bob”.)

You should always leave the campground cleaner than you found it.

Applied to programming, it means we should have the ambition of always leaving the code cleaner than we found it. Sounds great, but before we set ourselves to the mission we might benefit from asking a couple of questions.

1. What is clean code?
2. When and what should we clean?

Clean Code

What is clean code? Wictionary defines it like so:

software code that is formatted correctly and in an organized manner so that another coder can easily read or modify it

That, by necessity, is a rather vague definition. The goal of being readable and modifiable to another programmer, although highly subjective, is pretty clear. But what is a correct format? What does an organised manner look like in code? Let’s see if we can make it a little more explicit.

Code Readability

The easiest way to mess up otherwise good code is to make it inconsistent. For me, it really doesn’t matter where we put brackets, if we use camelCase or PascalCase for variable names, spaces or tabs as indentations, etc. It’s when we mix the different styles that we end up with sloppy code.

Another way to make code difficult to take in is to make it compact. Just like any other type of text, code gets more readable if it contains some space.

Although the previous definition mentions nothing about it, good naming of methods, classes, variables, etc, is at the essence of readable code. Code with poorly named abstractions is not clean code.

Organized for Reusability

Formatting code is easy. Designing for readability, on the other hand, is harder. How do we organize the code so that it is easily read and modifiable?

One thing we know, is that long chunks of code is more difficult to read and harder to reuse. So, one goal should be to have small methods. But to what cost? For instance, should we refactor code like this?

SomeInterface si = (SomeInterface)someObject;
doSomething(si);

Into this?

doSomething((SomeInterface)someObject);

What about code like this?

string someString;
if (a >= b)
  someString = “a is bigger or equal to b”;
else
  someString = “b is bigger”;

Into this?

string someString = a >= b ? “a is bigger or equal to b” : “b is bigger”;

In my opinion, the readability gains of the above refactorings are questionable. Better than reducing the number of rows in more or less clever ways, is to focus on improving abstractions.

Extract ’til you drop

Abstractions are things with names, like methods or classes. You use them to separate the whats from the hows. They are your best weapons in the fight for readability, reusability and flexibility.

A good way to improve abstractions in existing code is to extract methods from big methods, and classes from bulky classes. You can do this until there is nothing more to extract. As Robert C. Martin puts it, extract until you drop.

That leads me to my own definition of clean code.

• It is readable.
• It is consistent.
• It consists of fine grained, reusable abstractions with helpful names.

When to clean

Changing code is always associated with risk and “cleaning” is no exception. You could:

• Introduce bugs
• Cause build breaks
• Create merge conflicts

So, there are good reasons not to be carried away. A great enabling factor is how well your code is covered by automatic tests. Higher code coverage enables more brutal cleaning. A team with no automatic testing should be more careful, though, about what kind of cleaning they should do.

Also, to avoid annoying your fellow programmers it’s best to avoid sweeping changes that may result in check-in conflicts for others. Restrict your cleaning to the camp ground, the part of the code that you’re currently working on. Don’t venture out on forest-wide cleaning missions.

If the team does not share common coding rules, there’s a risk that you end up in “Curly Brace Wars”, or other religious software wars driven by team members’ individual preferences. This leads to inconsistency, annoyance and loss of energy. The only way to avoid it is to agree upon a common set of code rules.

With all that said, I have never imposed “cleaning” restrictions on my teams. They are allowed to do whatever refactorings they find necessary. If they are actively “cleaning” the code it means they care about quality, and that’s the way I like it. In the rare cases excessive cleaning cause problems, most teams will handle it and change their processes accordingly.

Cheers!

I’ve been looking for a way to display prettier code snippets on this blog. The SyntaxHighlighter by Alex Gorbatchev, nicely packaged into a WordPress plugin by Viper007Bond, had what I was looking for.

I’ve been using the plugin for a couple of months now and I’m quite happy with it. The only problem, for me, has been that it doesn’t support The D Programming Language. Since I couldn’t find any on the internet, I decided to implement a D brush myself. (It’s quite simple.)

Following Viper’s advice I implemented the support as a tiny WordPress plugin. If you’re using SyntaxHighligher Evolved and want to be able to display syntax highlighted D code, feel free to download shBrushD from my new Shared Stuff page.

Cheers!

I have a very simple philosophy when managing software development projects. It keeps me from derailing in this ever changing environment that is our craft. Regardless of whatever methodology and practices we currently use, I turn to these three questions for guidance.

1. Is the team as productive as it can be?
2. Is it doing the right things?
3. Is it delivering on expectations?

To me those questions represent the essence of project management. Finding the answers, identifying the impediments and removing them are what I consider my most important tasks as a project manager; not to impose a particular methodology.

Productive teams

Good questions to ask while analyzing the productivity of a team might be:

• Does the team contain the right people?
• Is it getting rapid answers?
• Is it getting quick feedback?
• Is it optimized for long term or short term productivity?

In software development, the only measure of team productivity is its ability to produce working software. So if you want to maximize your team’s productivity you should focus on those capable of creating software. Make sure they can spend as much time as possible producing customer value.

For that reason, I think twice before I ask my developers to perform some compliance activity, like writing a report. It’s almost always better to have someone else do stuff like that. If I need information I can always ask, and if writing a report is necessary, I can collect the information and write the report myself. That way I contribute to keeping the team focused and productive, which is more important than to ease my own work load.

Monitoring the team’s productivity is an important task of the project manager. I do this mainly by being around the team a lot. Taking an interest in each individual’s working situation and task at hand is the best way to pick up problems and impediments.
Other important sources of information (although not as efficient as MBWA) are the daily meetings and iteration retrospective.

If you’re really lucky; with the right material and inspiring goals, the team jells and becomes hyper productive. That is every project manager’s dream, but few get to experience it.

Efficient teams

But being productive is not enough. What we really want is efficiency, and to be efficient you need to be both productive and produce the right things. Right in this sense means the right features, with the right quality, in the right order.

To eliminate the risk of producing wrong features you need to work closely with the customer. Make the feedback loop as short as possible, preferably by utilizing an onboard customer, or at least by holding regular review meetings.

Another thing you’d really want to do is to have the planned features prioritized. For some reason many customers (here in Sweden at least) are generally unwilling to do this for you.
“I decided what I want to include in the release, didn’t I? All those features are equally important.”

The problem with leaving priorities to the team is that the system will be developed in an arbitrary order, most likely with the easiest features first. While that may have a value in some situations, the downside is that it decreases the project’s chance of success. The reason is, that without customer value as the leading beacon, chances are that you’ll end up with a lot more bells and whistles than you can afford. And when you find that out it’ll be too late to rectify.

Dealing with expectations

How do you define project success? Here is one definition:

If the output is in line with what the customer expects, the project is successful.

The good thing with this definition is that it implies another variable to work with besides output, namely customer expectations. If the answer is yes to both questions 1 and 2 above, we know we are maximizing the output. But if that still isn’t good enough, we have only one option left. We must change the customer’s expectations, or fail.

Again, the best way to tune the customer expectations is a tight feedback loop. If the customer sees the progress regularely, she will adjust her expectations accordingly, or have a chance to react to reality. Either way, the chance for success increases.

Never lose focus on the end goal.

Cheers!

I invested an hour watching a recorded speak by Martin Fowler and Neal Ford at some Paris convention. It was a well spent hour — as always with Martin Fowler — with some interesting angles on communication and feedback, and on why agile works. Especially the part regarding pair programming caught my attention.

According to Martin Fowler and his companion pair programming is an effective development practice because:

1. We can only use one part of our brain at one time, and
2. “The driver” and “the navigator” of a pair programming unit are using different parts of their brain and are thus complementing each other.

I have no idea if this is a proven truth, but it certainly conforms to my own experience with pair programming. The driver (the one with the keyboard) usually ends up in a state of completing-the-task-at-hand focus, while the navigator, a little more detached, makes bigger sweeps and thinks more on the big picture. For me pair programming has always resulted in better design, less bugs and a lot more fun.

If you want to watch for yourself, but don’t want to spend the full one hour, you’ll find the pair programming part 36:20 into the presentation.

Cheers!