Work Engagement

In my last post I talked about fear as an obstacle to be productive in development of a software project. Knowledge can conquer this fear, but there is also something else that can make people forget their fear. Engagement!

If you are really interested and motivated in your work you might just not be afraid of the huge codebase and the possibilities of errors and bugs when you do a change to it. In my opinion a motivated person often learn faster and are quicker to pick up on positive changes in their environment.

I often feel an "energy" when doing something interesting and it keeps me motivated. I read different blogs and I buy both management and system engineering books. This keeps me interested because I am constantly learning something new. But it is not what makes me actually tick, what does it is the actual tryout of an idea. Even if you only read it in a book or a blog. Does it work? If it does work it spurs me further in to the idea and I get motivated to continue to try new ideas.

How does one motivate others in the same way? To some extent I think it happens automatically when they are close to, or are working together with a person that has this energy. But is it enough?

My advice is to bring your colleagues or friends to the spot where you get your motivation from! Be an enabler and the motivator. Do not be afraid to bring new things to the table. Enable for others to bring new ideas into the work environment.

A day that nothing new is tried out can be a wasted day.. Can work be performed better for you and your company in any way?


Some of my favourite places to get ideas and inspiration:
The Practice of Leadership
Management Skill Blog
Management Craft
Agile Leadership
XP Meetup
*Technical*
Uncle Bob
(++)

Workshop: Legacy Code

It's true. We got it! We got legacy code..

To best describe legacy code I turn to one of the guru's on the subject, Michael Feathers:

[After all, there is an emotionally neutral definition of "legacy code." Legacy code is code from the past, maintained because it works. But, for people who deal with it day in and day out "legacy code" is a pandora's box: sleepless nights and anxious days poring through bad structure, code that works in some incomprehensible way, days adding features with no way of estimating how long it will take. The age of the code has nothing to do with it. People are writing legacy code right now, maybe on your project.

The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests.] ( full article and book )

We now have more than 180 000 lines of java code in my project. To me that is a lot of code. How can you have knowledge of the code to safely say that your change will not break any existing functionality? You can't!

There are many reasons to why you can't know for sure. Let me give you an example. One of the classes is almost 10 000 lines long and has methods that contains more than 500 lines of code. If we get a bug report and go in to that class to change something you can be sure that there is something in there waiting for you to mess it up. The class is impossible to change and it will take forever to fix this bug. And by fixing the bug you may actually introduce another , because someone was expecting that specific value in another part of the application.

The reason for expecting the bugged value can be many, but you can't know for sure if it will break something. Without a test, we can never know if that other functionality break when we change something.

Even with tests you can't be sure not to break anything. But at least your tests will lower the risk of not finding the bug you created with your change.


The tests help us have actual knowledge of the application. Not only can we read the tests, but we can actually get feedback from them when we do something to the code. This helps us to know more of the dependencies and the relations in the code. It helps us to understand the code better. But when you have 180 000 lines of code, do you really want to add another 100 000 in tests? No. But I do want to have tests around the changes i make and take small steps to create a safer place to work. Because it is fear that keeps us from attacking this monster class with our refactoring and our changes. Get rid of your fear by learning more about the code with tests.

In this spirit we have scheduled a small workshop for tomorrow to handle that fear. We will delete unused code and we will write tests for the code we are moving out of one of our biggest classes. We will discuss and learn about our code. With this knowledge of how to handle legacy code I hope that we will conquer our fear of changing code in horrible places.

This is knowledge in action!