Saturday, October 29, 2016

Brilliant hare?



We called him Tortoise because he taught us. - Lewis Carroll




In a conversation about work, a colleague mentioned that a person who was perceived as absolutely brilliant by everybody who knew him. People believed he was brilliant, because he was always coming up with answers for every complicated technical problem or question very quickly.

Being quick is important for success. ‘Quickly’ is one of the more popular words in LinkedIn recommendations. Speed-reading, speed-listening, and occasionally even fast typing, are considered good and important skills for technology workers.

Yet, quick can be an enemy of good. Quickly pushing out code typically leads to bugs, technical debt, and poor architecture. Quick decisions often turn out to be poor – or maybe not, but only if they happened to be lucky, rather than well thought through. The engineer everyone’s raving about for quickly fixing bugs, is quietly introducing dozens of new ones.

“Thinking, Fast and Slow” by Daniel Kahneman talks about the different ways people are wired to think, one by applying simple rules and pre-existing biases, another for consciously considering all available information. The ‘quick thinking’ leads to stereotyping, emotional, and subconscious choices. The slow option is the opposite – calculating, conscious and effortful.


It may be time to rethink what it takes to be brilliant. Slowly. 



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.