I released the intermediate package of my Test With Spring course. Take a look at the course >>

What I Learned This Week (Week 49/2013)

Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.

First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.

Second, I want to share my findings with you. I hope that you can use some of them in your daily work.

Let’s get started and find out what I learned in week 49.

Note: This week I make only four points because we celebrated our independence day on Friday.

What I Learned in Week 49

First, TDD ensures that you remember to implement all requirements.

I have written a blog post which talks about TDD and web applications. This week I noticed that I don’t always practice what I preach.

Sometimes I “forget” to use TDD and fall back to my old practice (write code first and tests afterwards). This week I happened to do just that.

Guess what happened? I almost forgot to implement one requirement!

Luckily I remembered this requirement before the code was deployed to production but I am pretty sure that this wouldn’t have happened if I had used TDD.

The idea of TDD is that you have to actually think what you have to implement before you write any code. I didn’t do this. Instead, I chose to code on autopilot and I made a mistake.

This time no harm was done because the implemented feature was so simple that I didn’t have to make major changes to my code. Thus, adding the missing requirement was quite fast.

This is not always the case.

It is clear that in the future I have to be more disciplined. Maybe I should add a Post-it note next to my screen so that I remember to write tests before I write the code.

Second, It is not always wise to automate.

I hate doing work which could be automated. The problem is that it isn’t wise to automate everything. Let’s think about the following example:

  • We have a task which takes two hours to do, and we have to do it once in a year.
  • Writing some code which does the same thing would take two days (18 hours).

When I do this work manually, it costs 2X to my customer. If I would automate this task, it would cost 18X to my customer. In other words, my customer would save money on the tenth year. Automating this task makes sense if the lifespan of the software is longer than nine years.

If it is not, don’t automate it.

Your job isn’t to rip off your customer. Your job is to maximize the value you provide to your customer.

Third, #NoEstimates aims to add value.

This week I read two blog posts which talked about #NoEstimates and budgeting. These blog posts are:

I realized that there is one crucial difference between #NoEstimates and the traditional fixed price offer which is based on work estimates:

#NoEstimates aims to maximise the value of the customer. The traditional approach is a budgeting tool and its goal is to minimize the costs of a software project.

The biggest problem which I had with #NoEstimates was that I had no idea how I could argue to the customer that fixed price offers which are based on work estimates are harmful. I wonder what customers would answer if I would ask this question from them:

Do you want to minimize your budget or maximize the value we deliver to you?

The answer to that question feels like a no-brainer to me but my experience has taught me that I might get an answer:

Both

Too bad that it just doesn’t work that way.

Fourth, Maintenance makes a great developer.

Maintenance is not sexy and it is considered to be a lot less fun than working in a greenfield project. To be honest, software maintenance has a really bad reputation. It is seen as uncreative and boring grunt work, and that is why “the best developers” of the company don’t often do it.

That is a shame because I think that if you want to become a great software developer, you have to do maintenance work! I think this way because if you do maintenance,

  • You have to live with the decisions you made in the past. If you made bad decisions, you will experience the pain caused by your decisions.
  • You will learn how to modify existing code without transforming it to a unmaintainable pile of shit. If you make ad hoc solutions without thinking the consequences of your decisions, you will feel the pain caused by these decisions later on.
  • You will learn to be patient. Software maintenance is not a hundred meter dash. It is more like a marathon. If you want to finish it, you will have to make decisions which are beneficial in the long run.

Software maintenance is extremely important and valuable job because the maintained software is one of most important asset of your customer, and the majority of software’s lifecycle costs are spend in the maintenance phase.

A maintenance developer is not “just” a maintenance developer. He has a great responsibility and a possibility to learn useful skills.

Don’t turn this opportunity down just because you think that you are too good to do software maintenance. You are not.

What Did You Learn This Week?

Share your learning experiences or other comments on the comment section.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

2 comments… add one
  • Cool, I really like this blog posts

    Reply
    • Thanks! I really appreciate your kind words.

      Reply

Leave a Comment