Agile Zone is brought to you in partnership with:

I am a Java expert with many years of developing applications and systems. I love learning new stuff and passing whatever I know to others. I love clean code, TDD and the simplest design possible. Eyal is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Mindset During Programming

02.25.2014
| 7019 views |
  • submit to reddit

I’m Stuck

Recently I found myself in several situations where I just couldn’t write code. Or at least, “good code”

First, I had “writer’s block”. I just could not see what was going to be my next test to write.

I could not find the name for the class / interface I needed.

Second, I just couldn’t simplify my code. Each time I tried to change something (class / method) to a simpler construction, things got worse. Sometimes to break.

I was stuck.

The Tasks

Refactor to Patterns

One of the situations we had was to refactor a certain piece in the code.

This piece of code is the manual wiring part. We use DI pattern in ALL of our system, but due to some technical constraints, we must do the injection by hand. We can live with that.

So the refactor in the wiring part would have given us a nice option to change some of the implementation during boot.

Some of the concrete classes should be different than others based on some flags.

The design patterns we understood we would need were: Factory Method and Abstract Factory

The last remark is important to understand why I had those difficulties.

I will get to it later.

New Module

Another task was to create a new module that gets some input items, extract data from them, send it to a service, parse the response, modify the data accordingly and returns items with modified data.

While talking about it with a peer, we understood we needed several classes.

As always we wanted to have high quality code by using the known OOD principles wherever we could apply them.

So What Went Wrong?

In the case of refactoring the wiring part, I constantly tried to immediately create the end result of the abstract factory and the factory method that would call it.

There are a-lot of details in that wiring code. Some are common and some needed to be separated by the factory.

I just couldn’t find the correct places to extract to methods and then to other class.

Each time I had to move code from one location and dependency to another.

I couldn’t tell what exactly the factory’s signature and methods would be.

In the case of the new module, I knew that I want several classes. Each has one responsibility. I knew I want some level of abstraction and good encapsulation.

So I kept trying to create this great encapsulated abstract data structure. And the code kept being extremely complicated.

Important note: I always to test first approach.

Each time I tried to create a test for a certain behavior, it was really really complicated.

I stopped

Went to have a cup of coffee.

I went to read some unrelated stuff.

And I talked to one of my peers.

We both understood what we needed to do.

I went home…

And then it hit me

The problem I had was that I knew were I needed to go, but instead of taking small steps, I kept trying to take one big leap at once.

Which brings me to the analogy of Agile to good programming habits (and TDD would be one of them).

Agile and Programming Analogy

One of the advantages in Agile development that I really like is the small steps (iteration) we do in order to reach our goal.

Check the two pictures below.

One shows how we aim towards a far away goal and probably miss.

The other shows how we divide to iterations and aim incrementally.

Aiming From Far

Aiming From Far

Aiming Iterative and Incremental

Aiming Iterative and Incremental

Develop in Small Incremental Iterations

This is the moral of the story.

Even if you know exactly how the structure of the classes should look like.

Even if you know exactly which design pattern to use.

Even if you know what to do.

Even if you know exactly how the end result should look like.

Keep on using the methods and practices that brings you to the goal in the safest and fastest way.

Do small steps.

Test each step.

Increment the functionality of the code in small chucks.

TDD.

Pair.

Keep calm.

Refactor Big Leap

Refactor Big Leap

Refactor Small Steps

Refactor Small Steps

Published at DZone with permission of Eyal Golan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)