Saturday, August 27, 2016

Work hard, aim high, fall, and keep going

I was told that this young woman in a sparkly dress is a top-level athlete at a local ice skating rink.  She came out on the ice with powerful confidence of someone who’s done that a hundred times. Indeed, she was very good - graceful glides, balanced turns, fast spins. Then she jumped. And fell. Got up and kept skating, and then jumped again. And fell again.

Those were complicated, high above the ice, many-turns jumps, and she did manage to land nicely a few of them. Still, she fell four times in a two-minute skating routine, all the way down on the ice. And each time she got up, picked up the beat in the music, and continued skating the program. More than that, she continued to attempt those high complicated jumps over and over again, never mind the falls.

The crowd was watching from the bleachers in awe. Down on the ice, this young woman was living through these, most likely unremarkable, minutes of her life – work hard, aim high, fall, and keep going at it. Throughout the evening, the skater kept attempting more jumps, sometimes landed nicely, but quite often continued to fall. She was the best, and that was exactly how she got to be the best, by pushing through the failure, the pain, the embarrassment, no matter the falls, jump after jump. 

Wednesday, June 29, 2016

Legacy code cycle

“Remember, code is your house,
and you have to live in it.”
― Michael C. Feathers
"Working Effectively with Legacy Code"

Every project goes through stages. First, there is excitement of design, green-field development, seeing things work. Then there are bug fixes, additional features that may or may not fit the originally designed architecture, little tweaks and changes to accommodate the cases not covered in initial development. And then there is support – making changes based on the usage patterns, keeping up with changing environment, fixing the harder-to-find bugs.

Successful projects go through these stages in a spiral: as time goes on, large sections will get re-written to update architecture, move to a new technology stack, fix the underlying issues of the old code base. And then more bugs will be written, tweaks and updates will be needed and will tarnish the shiny new design, and environment will continue to change.

No matter how many times we’ve been there, for most large successful projects, a large portion of the lifecycle is when the code base is full of slow-moving, bug-prone legacy code that is hard to work on. Eventually, an investment will be made to rewrite or refactor the worst pieces, yet a short while later the development organization finds itself facing the same problems again.  

At the same time, developers are being continuously schooled on writing better code, doing TDD, working with legacy code, but all this knowledge turns out to be very hard to put into daily practice.

Legacy code keeps happening, despite the best intentions.

Thursday, June 16, 2016

Are we ready for code review?

We have been talking about the better ways to do code reviews, and there are plenty. There are great tools to make code sign-off by someone other than the code author a required part of the process. It is important to keep code reviews short and casual. Very little code and only a few people should be involved in each event. Reviews should be done often, as much as a couple of times a day, and everybody on the team should participate regularly. There are ways to limit the conversation to the most important topics – logical flow, proper use of language features, good naming, while leaving formatting, test coverage, and many other issues to the automated code checkers.

The most interesting conversation, as it typically happens, took place after the formal presentation. The biggest problem of code reviews, and all other technical reviews, is that we, the developers, tend to take the critique as a personal assault.  People brought up multiple instances when they tried to communicate code feedback to a colleague, and instead their comments were heard as snarky and demeaning. We discussed learning to be nicer, working on improving Emotional Intelligence and social skills, making sure to provide comments on good things as well as bad.

However, this is just one side of the problem. There are at least two parties involved in delivering feedback: a person who endeavors to give the message, and the person who is to get the information. The person who receives feedback must be open and involved into how feedback is provided. In order to learn from and benefit from feedback, we also need better social skills and EQ, as well as trust in the system and the person who is delivering the feedback.