Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Archive for April, 2009

The most important skill of a software developer.

with one comment

A software developer has two skill sets, the programming skills and the non programming skills, from all this the most important skill of a software developer is “Getting things done”. Let´s prove it.

About the design

Some may say that the most important skill is to be a good designer, well, there is no such thing as good design. How many times have you been stuck discussing what design pattern is better,  if it´s better to use an abstract class or an interface, what design has better encapsulation…?

Design is overrated, good designs is like opinions, we all have one, at the end everything is about the execution. A good design always turns to be the design that complies with all the inputs of the application, and that can only be proved once that the code is done.

Keep in mind the following fact, for a given problem there are thousands of good designs that can be applied, but there is just one valid logic, no matter what design you pick, the logic behind it will be the same the only thing that will change is the structure.

There is a very unproductive type of software developer which insists in having a perfect design before start coding, that´s very common on junior developers that want to impress their colleagues, this type of developer can as well easily get stuck in a discussion with his colleagues about design.

I hear you saying… “But… We still need to have some sort of design on mind…”  Yes! The idea is to spend as less time as possible on the design, just make sure that is good enough by having an informal review, once that the starting design has been outlined give a developer the ownership of that task and keep doing informal reviews making sure that the quality of the code is high by making sure that it follows the most popular principles as the SOLID principles, DRY e.t.c.

About the code

Now I hear you saying “… You just said that we have to make sure that the quality of the code is high, so shouldn’t that be the most important skill of a developer?…”  Well, yes, I agree that is really important, much more important that the ability to come up with good designs, but still, there are these facts about code:

Fact 1. All the code which enters the maintenance stage will eventually become bad code.
Fact 2. Your code is always good, other people code is always not that good.
The “My farts doesn’t stink, your farts do syndrome”

So there’s a point in having good code as it will improve the time you will spend fixing bugs and doing changes, but all the code is doomed to become bad code eventually, so don’t expend too much time there either.

About the testing

The development is not done if it has not been tested, and from the developer point of view that means at least unit tested with a 80-90% coverage at least.

Another very common mistake on junior developers is to think that they are done as soon as they finish coding, I can’t stress enough how wrong is that, no matter how good the code and the design are, if they are not tested.


There isn’t a a better team that the team which is focus is “Doing things”, they will take care of having good code and the tests for you, they won’t care too much about designs, they will use just the enough time to do good code and they will provide you with the right amount of tests.

Written by Alberto G

April 30th, 2009 at 2:21 pm

Top 5 video conferences on Agile

with one comment

To me these are the top 5 video conferences on Agile, they pretty much cover all the aspects you need to know, my favorite ones are nº1 and nº4,  Enjoy it!

  1. This video is 7 mins long and summarizes agile
  2. Conferences made to GOOGLE employees in 2006 about SCRUM (1 hour long each):
  3. Conferences made to GOOGLE employees in 2006 about Agile Testing (1 hour long):
  4. 10 Ways to Screw Up with Scrum and XP
  5. IGDA Leadership Forum 08 – “Myths of Scrum” by Clinton Keith

Written by Alberto G

April 28th, 2009 at 10:53 pm

Are you doing agile or are you doing waterfall with some agile practices?

with 9 comments

Agile is not about following a subset of recommended practices (TDD, daily standup, task boards, user stories …), in the agile manifesto they are not even mentioned:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

You can be doing agile without performing any of the current recommended practices and you can perform all the recommended practices and still not be agile.

Lots of teams believe they are practicing agile just because they are doing standups or TDD… That’s like pretending to be a musician because you have the best instrument.

Agile is a culture not a process, Agile teams need to know the reasons for the principles stated in the manifesto, if a team is moving to Agile without understanding the philosophy behind agile, the team is at risk of keeping a Waterfall process with Agile practices.

The four main agile points are.

  1. Requirements change. Main point of Agile, all the inputs change during the software development process, actually most of them are yet to be discovered.
  2. Do it (right, right now). Forget about documentation, big analysis, big plans… Just do it, do it now, do it right.
  3. Good code over BDUF (Big design upfront). Focus on building good code as not only your code will be better, but also good code will end up creating good designs.
  4. Deliver value as soon as possible. Have deliveries and demos as soon as possible, don’t do anything if it doesn’t bring any added value to the final product.

If you stick to this four points, no matter what practices you follow, you are an Agilist. The different methodologies, like XP or Scrum, are just a set of recommended practices/tools to help you drive the software development process to handle the 4 main points. As an example XP will focus on good practices for having “Good code over BDUF” (TDD, Pair programming..),  Scrum will focus on Deliver value as soon as possible (User stories, Sprints) Do it, right, right now (Daily standup)…

Ask yourselves, do I believe the previous four points? If you don’t, you will probably have problems to become an Agile Software Developer, or you may end up doing Waterfall with some agile practices.

Written by Alberto G

April 27th, 2009 at 11:49 pm

7 best practices for taking decisions in the development team

with 5 comments

Importance of Decisions.

During the software development process, a lot of decisions have to be taken, they may be related to design or architectural issues, testing approaches and many other different areas… What follows is the 7 best practices for making the most when you are about to take a decision in your team

The 7 Good practices.

1.- Have a clear goal. (A vision statement)

Good Example: “We need to decide on what technology we are going to use for the UI of the next product”.

Bad Example: “What are we going to do next week?”.

Write it in a board making sure that everyone can read it. (Importance of boards are highlighted in the 6th point)

2.- Gather all the inputs.

As explained in my previous article about inputs, outputs and actions, inputs are the clues that leads us to find the best solution, in order to take the best decision we need to make sure that we  have the appropiate inputs.

Good Examples: “We are not tight to use the same technology for the backend and the frontend”, “Inside the team there is strong expertise in technologies x,y and z”, “The dead line for the UI is in one month”…

Write them in the board as well. (Importance of boards are highlighted in the 6th point)

3.- Keep the discussion objective

Opinions should be translated into facts and numerical arguments, if not it will be impossible to compare with each other, keep an eye on the following symptoms of a non objective discussion

– Don’t use Buzz words/be vague/use the word “should”.

Some examples: “This approach should be easy”, “performance is going to be bad”, “what I am suggesting is a best practice in the industry”….

– Don’t let people speaking in future terms (if they are outside of the scope).

If the scope of the solution doesn’t include any point that states that the solution has to be time proof, then don’t let people use that argument to discuss. Example: “Well, I don’t like this logging approach because there is too much overhead data, and maybe in one year we will run out of space”.

– Avoid people from first being understood rather than to understand.

Lots of time two persons argue about something but they are basically saying the same thing with different words, two tricks to avoid this are:

– Don’t let people interrupt
– Make them rephrase other people point with polite questions like: “Sorry Tom, just to make sure you understood Andrew point could you rephrase it?”.

4.- Don’t make it personal

If deciding A or B becomes deciding if Bob is better having good ideas than Harry, your may be discussing for the next two weeks.

– Separate opinions from people.

Write them in the board and call them with letters or numbers, NEVER write besides them who suggested the idea. Try to mix the best from all the ideas rather than selecting just one person approach.

– Be careful with the egos.

Software developers usually have huge egos, actually the better is a developer, the bigger is his ego.

5.- Timebox the decision, make the decision process takes as short as possible.

As we will see in the last part of the article it’s not about the idea is about the execution, but we still want a good enough decision, as a rule of thumb, if the vision is clear, the inputs have been discovered and every one have expressed their opinion, it shouldn’t take longer than 15 minutes to make a decision.

6.- Keep Focused

Book a room with a board. The idea of having a board is to picture all that has been discussed, at least in the board there should be the “Vision” (Point1), “Inputs” (Point2), all the different alternatives, and the final decision.

Don’t discuss anything outside the scope of what needs to be decide.

Focus on “why” rather than “how” or “what”, just make them explain why a solution is better or worse, is very easy to get stuck in implementation details.

Make people describe their opinions in short sentences and write them on the board.

7.- Make everyone participant of the final decision.

Have a final solution that includes the best from every alternative, thank everyone for their effort.

At the end all is about the execution, not the idea.

Even being important to have a good decision, what matter is the execution, that’s why point5 focus on make the decision making process as quick as possible.

Written by Alberto G

April 24th, 2009 at 7:47 am

Software Developer = Craftsman + Private Investigator

with one comment

In the software development industry is common to find a feeling of uncertainty regarding the reason behind so many software projects failing. One approach taken to find answers to this question is to compare ourselves with other successful industries to apply the same lessons learned and best practices from them. We mostly have been compared with strong engineering industries, we have even imported from them some terminology like “Architects” or some very waterfall oriented methodologies.

It is now a recent and every time more followed opinion that coding is a similar activity to that performed for the craftsmen…. but! The definition it’s not complete, the craftsmanship would just cover the coding part of the software development process, missing something from the picture…. The private investigator!!!

Let’s check the main characteristics of the private investigator job.

  • It’s impossible to provide an accurate estimate of how much and how long is going to take the investigation.
  • The customer doesn’t really know what the investigation is about, they just have a feeling of something wrong or they need to fix a problem.
  • A few clues are provided at the beginning, most of the clues are to be discovered or refined during the investigation.
  • Some clues are misleading.
  • No matter how good the clues are if they don’t lead to a final verdict.
  • Even if a final verdict is being decided, if it’s not the verdict expected by the customer, he is not going to be happy.
  • Most time the verdict has to still be validated by a judge.

If you still doubt about the similarities, find below again the previous points with a few changes.

  • It’s impossible to provide an accurate estimate of how much and how long is going to take the Software development.
  • The customer doesn’t really know what has to be developed, they just have a feeling of something wrong or they need to fix a problem.
  • A few requirements are provided at the beginning, most of the requirements are to be discovered or refined during the software development process.
  • Some requirements are misleading.
  • No matter how good the requirements are if they don’t lead to a shippable product.
  • Even if a shippable product is released, if it’s not the product expected by the customer, he is not going to be happy.
  • Most time the product has to still be validated by the users.

You can actually even take similarities between famous PIs and different software developer stereotypes.

  1. The James Bond developer: Excellent developer, good job, no mistakes, knows when to use the force and when to be diplomatic.
  2. The Jason Bourne developer: Good developer, gets the job done, not very careful sometimes leaves a mess behind that needs to be fixed.
  3. The Columbo developer: Not brilliant, get his job done.
  4. The Agent 86 (Maxwell Smart) developer: A bit more skilled than The Pink Panther, still needs some help.
  5. The Inspector Jacques Clouseau (The pink panther) developer: Useless, most of the times someone else will solve the problems for him.

[polldaddy poll=1555394]

Written by Alberto G

April 20th, 2009 at 1:36 pm

The two main skill sets of a software developer

with 2 comments

A lot has been written about the differences between Software developers and Programmers, two opposite examples on this subject would be:

  1. Eric Sink from Eric.weblog() says that that there are two types of professionals, the Software developer and the programmer.
  2. Raymond Lewallen from says that conceptually Software developer and programmer are the same.

Well, I believe they both are right:

Software development teams should be flat organizations, that means that there should be just one role in the team, the software developer, (or whatever you want to name it: programmer, engineer..). This will align with Raymond’s article.

The Software Developer has two main skill sets, Programming Skills, and Relevant Non Programming Skills. This will align with Eric’s article.

In summary:

  • The Programming Skills tell us how good a software developer is designing, coding and testing.
  • The Relevant Non Programming Skills tell us how good a software developer is finding risks, understanding requirements, coaching other peoplefacilitating work in the team, planning…

Relating this with my previous article about inputs, outputs and actions, The programming skills will help creating better outputs, the Relevant non programming skills will help creating better inputs and actions.

The programming skills are taught at school, so you can’t expect from junior developers good Non Programming Skills, senior developers are almost guaranteed to have good Programming Skills, but not always good Non Programming Skills, that’s why those are the ones that usually set the difference between two senior developers.

A team needs a balance of these two sets of skills, ideally the team will have one or more leaders which will have outstanding skills for both skill sets, these leaders should coach and facilitate the other software developers work if they are seniors, or babysit them if they are juniors.

Software development teams should be like flat mini organizations where decisions are taken in an agile manner. In a healthy work environment developers with better skill sets should get the promotions, and they should be encouraged to act as coaches and facilitators and their authority should be earned rather imposed.


This is part I of II articles, in the next article we will discuss about the professions that better match with software developers based on the different skill sets,  (I am sure they will surprise you),  so stay tuned!!! (There’s a subscription link on the right navigation bar in the blog)

Written by Alberto G

April 18th, 2009 at 1:14 am

Forget about requirements, Software Development is all about inputs, outputs and actions.

with 8 comments

One of the worst habits from traditional Software Development is to give different names to all the artifacts that somehow affect the software we have to deliver, Requirements, bugs, risks, constraints…  Are just the same, they all are inputs to the project, and they should be treated equally.

Inputs are the clues that leads us to find the best solution for our customer, their main goal is to help the stakeholders understand the problem they have to solve, they should be managed as an unique entity.

Let’s see a simple sample of some inputs working together:

  1. The customer wants the user to be able to pay with credit card in the checkout page of his e-commerce site.
  2. There’s an existing module for processing credit card payments in-house.
  3. The architect believes there’s a security risk in the credit card implementation in the in-house module for processing credit card payments.
  4. The development team is short on resources for the next month as they are helping another team fixing some priority 1 issues.
  5. The customer needs this functionality ready in the next month.

When enough inputs have been gathered an action is decided, an action is a sequence of tasks agreed by all the stakeholders which it’s only purpose is to overcome whatever the problem is expressed by the inputs. Most of the times this action will trigger some sort of software implementation.

For our previous inputs the following action is decided: “Implement a simple credit card payment mechanism based on the in-house module already created, keep an eye on testing the security risk”.

This inputs-action schema is actually in every single developer heart, it’s just because bad work habits, we keep having different documents for risks, requirements, design…  and we keep giving the requirements the main role.

  1. There’s no point to just have the requirements as base to our actions, they are just a type of inputs.
  2. All inputs should be seen and managed together making easy to see the whole picture of the problem.

As I said in my previous article about requirements, they are not likely to be clear at the beginning of the software development process, this applies not only to the requirements but to any type of inputs,  actually inputs have a very dynamic and simple life cycle which consists of the following stages.

  • Discovery. The input has been identified or moved back to this status and it’s  best description in plain English is being created.
  • Idle. The input has been described, no action has been taken yet to generate an output for it.
  • Generating output. An action or actions addressed to solve this input, (and probably some other inputs), have started and they are in it’s process to completion. In the “Generating output” status the inputs are refined and new inputs are discoverer, some others may be canceled.
  • Validated. The related output for this input has been completed, the stakeholders have agreed that the result is as expected.
  • Closed. There is enough confidence that the validated input is unlikely to change.
  • Canceled. The input has been canceled.

Let’s put this into some context, let’s take the 5 input samples scenario described above.

  1. The customer wants the user to be able to pay with credit card in the checkout page of his e-commerce site.
  2. There’s an existing module for processing credit card payments in-house.
  3. The architect believes there’s a security risk in the credit card implementation in the in-house module for processing credit card payments.
  4. The development team is short on resources for the next month as they are helping another team fixing some priority 1 issues.
  5. The customer needs this functionality ready in the next month.

The status for these 5 inputs will be “Discovery” while we are gathering them, then, once that we think the inputs are mature enough we will move them to the “Idle” status, when we are sure about the action we want to take and we start taking it, we move the status of the inputs to “Generating output”, once that the output is finished, some inputs can be canceled, some others can be called validated, some other can remain in Generating output, idle, or even can go back to Discovery.

As an example, let’s say that while we were generating the output for the previous 5 inputs, (they are in the status “Generating output”) , we found that:

  • The input number 3, about the risk in the in-house module,  doesn’t apply anymore because we have done some proofs of concept that shows that the module is completely reliable, so we decide to move its’ status to  “Canceled”,
  • New inputs are created regarding what is the best design approach to suit for this particular implementation
  • More inputs are created for every bug found during the test phase

Finally we complete the implementation and we show the results to the customer who’s happy about the output, so we decide to move their status to “Validated” and after a while, when all the changes to the checkout page are completed we decided that is safe enough to change the status of these inputs to “Closed”

Change always happens in a project, and not necessarily only on the requirements, but in any input, we need to have the ability to manage this changes and track them to make sure that we embrace change so we deliver the best solution.

The best way to find all the inputs is to understand that they are hidden to us until we don’t start working the outputs (normally software implementations, but could be documents…), we just have to make sure that before we start working our inputs are good enough.

Written by Alberto G

April 15th, 2009 at 7:04 pm

What is good software development?

with 7 comments

A bit of history: Waterfall

When I was a student I was taught that the life cycle of software is very simple, is just a straight process defined by the following consecutive activities: Analysis, Design, Coding, Testing and Deployment which by that time made a lot of sense to me, oh! life was easy….

Then I start working as a programmer, and I saw that life cycle applied on practice. I saw the project manager doing an amazing planning effort, the architects and designers doing thousands of UML diagrams and the programmers trying to implement those designs as well as possible to hand over to the testers… but, the plan was always inaccurate, the design was 40% wrong, the implementation took forever and at the end there was just one day for testing.
Conclusion: The process (Waterfall) is prone to a lot of failures, misses planning and doesn’t generate the expected output.

Not all the waterfall projects were claimed to be a failure, some of them were claimed successful, but amazingly even for those projects it was normal to find failures like that they needed extra time/money, didn’t deliver 100% of the functionality, some parts of the software were not as the customer expected…
Conclusion: Even when claimed as successful most waterfall processes contain quite a lot of defects at the end of their life cycle.

Can you imagine acceptable in some other industry that what it fails is the process to create a product, not the product itself?
Conclusion: Let’s think it all over again.

The requirements

What is software development? A traditional answer would be something like: “Software development is the process where we get some requirements and we translate them into software”, then everything is about getting upfront the correct requirements, right? Well, after 10 years of experience developing software, I can only say that that’s wrong, let’s see why:

1.- It is impossible to get all the requirements upfront

Anyone who has been in any medium/large size project knows that there are always big mistakes/leaks in the requirements gathering phase: sometimes you don’t get all the requirements, sometimes they are wrong, sometimes there are missing requirements for some parts of the application, sometimes they just change… The requirements of an application will only be clear when the application is completed.

2.- Customer only have a vision and few ideas, they don’t know about requirements

Is well known that in order to gather the requirements we have to meet with the stakeholders, interview them and extract the requirements, how do we do that? By asking lots of questions and refining their answers into requirements, well, the truth is, customers and stakeholders don’t know what the requirements are, they just know about the big picture and requirements are about details.

3.- Requirements are goals not iputs

The biggest misunderstood of all is to think that the requirements are inputs to the project, that’s false, requirements are goals, are the small pieces that need to be discovered that make all the objectives and visions come true.

4.- Requirements can only be validated when they are imlemented

Requirements are just the representation in plain English of some software behaviour, so a requirement is likely to be wrong until we don’t validate its implementation.

5.- Requirements are linked with each other by a very complex, very difficult to predict net of dependencies.

Even after validating a requirement through its implementation, it’s possible that a change in some other requirements causes this requirement to change. You can only be 100% sure of the validity of a requirement, when all the other requirements have been validated.

What is good software development?

As opposite to the traditional approach where requirements are the base of software development, I propose an approach where the base is some ideas/visions and we help the customer to translate them into software by discovering simultaneously the requirements and their implementation.

Good software development is the process where we help the customer to figure out what software they need by finding all the requirements while we build them.

Written by Alberto G

April 13th, 2009 at 8:34 pm