Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Archive for July, 2009

Software development: Engineering or Craftsmanship?

with 3 comments

Wether Software development is an Engineering or a Craftsmanship is one of the hottest topics in the software development community, and it generates many articles and opinions as these two articles which have been brought to my attention lately and which I highly recommend you to read.

  • Tom DeMarco.  (Author of  Peopleware: Productive Projects and Teams)- Software Engineering: An Idea Whose Time Has Come and Gone? (PDF).  “My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.” Saw in codinghorror.com
  • Charles Fishman. They Write the Right Stuff. (An article about the software developed by NASA).[…] This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, […]each 420,000 lines long-had just one error each.[…]How do they write the right stuff? The answer is, it’s the process. […]The product is only as good as the plan for the product.

So who is right, Tom DeMarco, or the NASA, well, I wouldn’t dare contradicting any of them, I actually believe they both are right! What is wrong is the question: “Software development: Engineering or Craftsmanship?”. There isn’t an unique way to go, they can be both applied, is just a matter to identify which approach suits better to the software that has to be developed.

So… what approach to use in each case: Engineering or Craftsmanship?

Most commercial projects can’t simply cope with an Engineering approach, can you imaging building an e-commerce site that has to be fully specified and designed upfront with no changes after and without early feedback? I don’t think so, what is amazing is that there are still some companies that try to use an Engineering approach (most usually waterfall) to develop this kind of software. Waterfall only works if you follow all of  its steps and if you don’t make any change to the specifications when you start coding, when a waterfall project fails, most of the times is not because waterfall is wrong but because waterfall doesn’t adapt to the type of software they want to build, Waterfall doesn’t work with software that evolves while it’s been build, for these cases is better to follow a craftsmanship approach.

Craftsmanship approach characteristics

  • Specification and design are created in an on-going basis.
  • Gives plenty of  room for change.
  • Focus on people and communication.
  • Early feedback.
  • High rate of errors, but the application is functional.
  • Uncertainty on how the final product will be.

For some other companies what is essential is that there are no surprises and that the software doesn’t have any errors at all, that’s typical from critical systems as Aircraft software, Rocket software, Trains software… In this case an engineering approach is essential.

Engineering approach characteristics

  • It requires full specification and design beforehand.
  • Focus on processes and contracts.
  • It does not allow room for change.
  • Late feedback.
  • No surprises.
  • No errors (Almost).

Written by Alberto Gutierrez

July 23rd, 2009 at 7:22 am

What makes a great Software Developer?

with 6 comments

The cycle of the Software Developer.

The software development industry changes so much and so fast that each day you are going to become a worse developer than the day before if you don’t keep learning and adapting. This statement has three main consequences.

  1. If you don’t do anything to prevent it, no matter how good software developer you are now, you will eventually become a bad software developer.
  2. To make sure that in the future you are going to be as good a software developer as you are now, you need to learn and adapt to the upcoming changes that are directly related with your job environment.
  3. To be a better software developer, you have to take learning and adaptation one step ahead.

Great Software Developers

Given this apocalyptic scenario where nothing is for granted, what makes a great software developer is not only his ability to learn and adapt but also going one step ahead of those who just do the necessary for not becoming obsolete..

Learning

  • Technical knowledge becomes obsolete
  • New methodologies and processes for developing software are created.

Adapting

  • Software development is a process which requires constant adaptation. For instance, you will work on other people’s code. You need to adapt to its style and structure to understand and maintain it.
  • Change happens continuously during the software development. Changing requirements, technologies…
  • You won’t always get to do what you prefer to do. But you have to do it, so you better adapt.

Good Software Developers vs Great Software Developers

Good software developers and great software developers have two things in common- their productivity and quality are high. The main difference is that Good Software Developers that don’t keep learning and adapting will become worse developers every day while Great Software Developers will keep improving.

Are you a Great Software Developer?

Sometimes it is hard to tell how good we are at learning and adapting. These are a few indicators that can help you to determine it.

  • You can learn a new technology very fast.
  • You can maintain legacy code.
  • You are good no matter the development process used, waterfall, CMM, XP…
  • You can switch between programming languages easily.

But the main indicator to know if you are a great software developer is: Great software developers are better software developers than the day before.

Written by Alberto Gutierrez and Mike Baxter

July 21st, 2009 at 6:53 am

3 tips to know how good is the candidate you are interviewing

with 10 comments

One of the most critical moments for a team is when they need to hire a new programmer, choosing the right people is what makes the difference between great teams and poor teams.

Some companies are tempted to have short selection processes because the cost involved is high, but hey forget that the cost of having the wrong guy in the team is much higher.

These are my three tips to help you hire the right programmer for your team

1.- Make the candidate draw a high level design.

This activity will help you to know how good designer the candidate is.

Ask the candidate to explain in a board the architecture and design of some previous application he has developed. This will allow you to engage him in an open conversation, by the end of it you should be able to answer yourself the following questions:

  • How good was he explaining the design? One of the most important qualities of a programmer is his communication skills, is almost as important as the quality of the design, if the candidate is not  able to explain it in a clear, concise and focused manner, then how is the rest of the team going to understand it?
  • How good was the design?
  • How good was he answering your questions? You want to make sure that the design he is explaining is his design, so ask him a few questions and see how he answers you, based on that you should be able to tell if he is really the author of the design.

2.- Make the candidate write some code.

This activity will help you to know if the candidate is able to produce working code in a realistic time frame.

There is a very popular article from Joel Spolsky “12 steps to become a better code” where he states as point 11 “Do new candidates write code during their interview? “, well, I couldn’t agree more, that will give you an unique perspective on how the candidate really performs, there are still a few considerations.

  • Leave him alone in a room with a computer, just come back when the time is over.
  • Make him code using the same tools he would use in the position he is applying for.
  • Leave him enough time to complete the task

3.- Make the candidate review some working code.

This activity will help you to see if the candidate has a good sense of what good code is and will help you to determine how good he is reading code.

By asking the candidate to write some code, you should have some idea on how clean his code is, but that could be a false impression as you will be judging based on a piece of code which has been written under quite pressure, that’s where this other activity will help you, hand him over some poor functional code written in the language he is applying for, and leave him alone with it for as much time as you think he will need to review it, then come back and ask him the following questions.

  • What is the purpose of the code?
  • What do you think of the code, is it a clean code?
  • What would you change from the code to convert it into clean code?

Written by Alberto Gutierrez

July 16th, 2009 at 8:43 am

Top 10 people (+1) that have influenced me as a programmer

with 8 comments

What follows is the list of the 11 most influential sources I’ve had, any software developer should be able to learn very valuable lessons from them.

1.- Kent Beck

2.- Martin Fowler

3.- Robert C. Martin (aka Uncle Bob)

4.- Craig Larman

5.- Steve McConell

  • Author of one of the most popular programming books-  “Code Complete“, this is one of the first books where coding is seen a as craftsmanship activity rather than an industrial one, he is considered to be one of the most influential authors ever, he is also author of “Rapid development

6.- Mike Cohn

7.- Kathy Sierra / Bert Bates

8.- Ward Cunningham

9.- Andy Hunt / David Thomas.

  • Authors of “The pragmatic programmer“,one of the must influential books for programmers ever written, in it they introduced some of the most important principles applied today in the software development industry, as DRY and “broken windows“.
  • Andy Hunt is also signatory of the Agile Manifesto.
  • Dave Thomas has published a series of exercises to help programmers to improve their coding skills called code katas.

10.- Erich Gamma.

And the most important one: The programming community. (YOU)

The most important influence for me is the whole programming community, that includes all the people I’ve read articles from in the internet, and particularly all the people that has used their time to write in this very same blog their comments, to all of you, THANKS!

Written by Alberto Gutierrez

July 13th, 2009 at 7:04 am

5 top non-technical mistakes made by programmers

with 49 comments

There are two sets of skills that a good software developer needs to cultivate: technical skills, and non technical skills. Unfortunately some developers focus only on the technical part. When this happens they will develop some bad habits from which the following are the 5 top non-technical mistakes:

1.- Lack of discipline.

“Discipline is the bridge between goals and accomplishment.” Jim Rohn.

I’ve always thought that discipline is one of the most valuable skills, not only for being a software developer, but to be successful at any other area in life It is also true that usually it is very hard to find people who are both brilliant and disciplined.

Steve Pavlina highlight the 5 pillars of self discipline…  “[…]Acceptance, Willpower, Hard Work, Industry, and Persistence. If you take the first letter of each word, you get the acronym “A WHIP” — a convenient way to remember them, since many people associate self-discipline with whipping themselves into shape.[…]” I highly recommend to read his series of articles in self discipline.

As I explained in my previous article: 5 tips for creating good code every day, my personal approach is to follow these steps every day.
homer-simpson-doh

  • Have your own to do list for the day
  • Do one thing at a time
  • Do it right
  • Don’t finish something until it’s completely done
  • Better late than sorry BUT better sorry than never.

2.- Big egos.

My experience says that big egos and programmers go hand by hand, the main problem of having a big ego is that it actually prevents you from realizing that you have a big ego, a few indicators that may help you to know if your ego is way too big are:

  • You consider yourself the best programmer.
  • You block conversations.
  • You ask for code reviews not to get criticism but to show how good your code is.

There are many good articles about programmers and their ego in the Internet, I would recommend two of them, this article from Mike Bernat: Egoless programmin and from stackoverflow.com this discussion thread.

3.- Being a bad communicator.

“If I am to speak ten minutes, I need a week for preparation; if fifteen minutes, three days; if half an hour, two days; if an hour, I am ready now“. Woodrow Wilson

As human beings communication is our main activity. Being a good communicator is hard but essential in our profession, we are continuously exchanging opinions about designs, code, having peer reviews, writing documentation, trying to convince someone else that our design is better, writing code…

Good communicators are those people that when they are explaining something, their explanation is:

  • Focus. They just talk about what is need to be understand.
  • Clear. Easy to understand.
  • Concise. Nothing to be added, nothing to be taken.

For being a better communicator, I have two advices:

  • If you think you are not a good communicator, prepare what you are going to say until is focus, clear and concise.
  • If engaged in a conversation, first listen, then think and then talk.

There are a few more tips for improving communication when having a meeting in this previous article I published “7 best practices for taking decisions in the development team“.

4.- Forgetting about the customer.

“If we don’t take care of the customer… somebody else will.”

You are there just for one reason- your customer. It’s easy sometimes to forget this point. I have been in teams where focus was on technologies and platforms rather than in having a happy customer. We would expend months creating a framework that didn’t deliver any value to the customer, and by the time we were about to start using it, we would discover that it won’t fit our user needs.

5.- Not prioritizing the work properly.

Developers who are always gold plating, researching new and more interesting technologies, over engineering solutions or just doing whatever they find more cool are impediments to the project, I’m not saying that is not normal to engage into lateral activities from time to time, we all need distractions, but if you find yourself usually in the previous situations you may reconsider the way you prioritize your work, again I will recommend you to read 5 tips for creating good code every day.

Written by Alberto Gutierrez

July 7th, 2009 at 9:43 am