Technical Debt

Habitable Code / Clean Code

Let's define Habitable (or, Clean) Code as one in which programmers coming to code later in its life can understand its construction and intentions, and change it comfortably and confidently.

Technical Debt would be the work that remains to make the code habitable.
The debt metaphor was coined by Ward Cunningham, to illustrate that like with financial debt, the cost of change grows over time. Instead of money we borrow time. 

when software's technical debt is not paid, bugs come and break its legs

— Ron Jeffries (@RonJeffries) April 28, 2012

Every developer who spent some time with code experienced this: a design that was once elegant turns over time to a big ball of mud, to spaghetti. Complexity grows, and changing the code feels like walking through a mine-field. How do we get back to safety?

What makes us feel unsafe changing code?

Mostly, a culture of laying blame. Fear driven development. Addressing that has less to do with technical debt, but I explore some ideas about safety here. 

What else? Here's a partial list:

• Low automated test coverage
• Late, high cost, infrequent integration testing milestones 
• Failing test cases
• Code anti-patterns (static analysis warnings)
• Low cohesiveness of classes
• High cyclomatic complexity
• Various architectural anti-patterns that make the design hard to understand 
• Known (and unknown…) bugs
• Missing API documentation
• Duplication
• Long methods with deep nesting
• Misleading names and metaphors
• Lack of adherence to coding standards (inconsistent style)
• “TODO” comments

How did we let our tests and code get this way? Could be any number of reasons, but essentially they would fall under these 3 categories:

• Planned decision - being aware that the code needs more work we release anyway due to some constraint but intend to fix the code in the immediate future
• Accidental - and here the big question is do we learn from it and become more competent - or we simply don't know any better
• Reckless - we don't give a damn 

I would assume that the first one is a desired state, where you occasionally take on debt and pay it back before it becomes a big problem. Dealing with the last one is not about tools and techniques - there some deep underlying problem to address. 

But from what I've seen, it's mostly accidental, and here we can improve by learning ways to assess, avoid and reduce technical debt.

Assessing Technical Debt

Some frameworks (like sonar) are good at providing metrics and visualizations of different aspects of technical debt, integrating static code analysis data regarding style, anti-patterns, complexity, duplication, cohesiveness and information regarding test coverage. 

Like any tool - you need to know when and how to use it. I'll let you in on a secret: 

     You don't have to fix all of it 

Remember why we care about technical debt? It increases our cost of change. But maybe there are areas of the code we don't really change that much? 

What we need to care about is code we change often. This is where the mess hurts the most.

Michael Feathers: getting empirical about refactoring.

Because of that attribute, assessing the amount of technical debt is not as important as dealing with it. Some would even say dont waste time tracking technical debt with some very good reasoning.

Preventing New Technical Debt

As a strategy you need to change course - commit to a new behavior. The team needs to take upon itself some new rules and stick to them. If they have a definition of done, this might be a good place to add some helpful practices. But drawing a line, saying "from this day on..." is a good start.

Some concrete practices:

• Test-driven-design
• Group design (whiteboard sessions)
• Education & team agreement (e.g. adhere to „clean code“ practices)
• Pair programming / continuous code reviews
• Continuous integration + automated tests + static analysis tools

A note regarding tools: they won't help unless regressions are visible (dashboards which the team actually sees) with a clear agreement on what we do whenever there's a regression. 

Hint: fix it. Now.

Paying Back Our Old Debt

To reduce debt, you are probably going to identify an area to improve, pad it nicely with automatic tests, and refactor. Rinse, repeat. Since there's always room for improvement you need some way to balance the effort that goes into this kind of work with your need to build stuff. So unless some major rewrites are needed, the most effective, and simple way I know of is what Uncle Bob calls "the good boy scout rule", paraphrasing on "Always leave the campground cleaner than you found it". 
Another option is to set goals based on metrics if you are using something like sonar, but again - this is easy to get wrong and wastefully get people fixing code that's hardly ever touched.

The Curse of Knowledge

So now you know. Its no longer accidental from now on. How did we call not taking action to deal with known technical debt? Oh, right - reckless. 

It might be a hard sell for some stakeholders if you need to make some meaningful investment to change course, but if they care about the future of your product, the sooner you can agree, the better. 

Further Reading

Building Real Software (Technical Debt)

Agile Practitioners 2015

After last year's conference, the guys from Practical Agile decided to "open source" the conference - the conference was community driven by a volunteering steering team. This year the conference offered a full 4-track program under the title "learn something new" making it harder than ever to choose the sessions.

Keynote: Unicorns, krakens and self-organized-teams

a delegation board

A slimmer version of Angel Medinilla (@angel_m) returned to get things going with his high paced, humorously sketched view on the road (and pitfalls) to hyper-performing teams. Some of the notions come from management 3.0 which is not a coincidence, as Angel is one of the M 3.0 trainers. Some topics to follow up on may be the Agile Fluency Model, the "Agile Kaizen" book and delegation boards.

Morning Sessions

Gil on #NoEstimate

Gil Zilberfeld's talk, “To Estimate or #NoEstimate” talked about the #NoEstimate movement, why people want estimates, what are the problems with estimates and what could be useful alternatives.

Meanwhile I missed, among others, Uri Nativ's "Missing Lecture" about the difficult-to-deal-with gap between the agile coach/leader's perspective and the teams' view on the agile change initiative. I love the slides (form and content).


Next, Lior Friedman, talked about code smells, and their less (in)famous cousins: Test Smells. Learning to identify them can help improve the system. After all, TDD is a way to write well designed software. Problems in the tests often tell you of problems in the design, or even in your process.

Afternoon Sessions

Three short sessions:

One of Barak's slides

• Gull Ben-David (from MyHeritage) shared why QA people make good scrum masters
• Ran Deri and Noam Zweig (from CyberArk) gave some insight on their experience dealing with Technical Debt systematically. Interesting mix of tools (such as sonar) and assessment (using a survey by Gil Broza) to actually track, negotiate budget and set goals.
• Barak Benjo (Cisco) gave tips for Agile Testing in a legacy environment

In a session I missed, Yuval Yeret (happy birthday!) gave a talk about an effective way for managing an agile transformation.

"Lean Lens" - observing our results

Andrea Darabos conducted her "Lean Lens" workshop. It is essentially a role playing game each team gets a scenario to play out. Some participants act, simulating the different roles, while others observe, trying to identify the 8 types of waste (better known as the 7 wastes + unused skills).
You can download the game here (developed by @bazila and @ADarabos)
Interesting takeaway - try set up a board in the team room to collect instances of the 8 wastes as they happen, and deal with them in the retrospective. Hey - these are "process smells"!

Meanwhile, Eyal Golan talked about working with legacy code. I was told it was interesting and practical.

The last track session actually had 5 options, because Angel agreed to give an improvised sketching workshop where we practices some basic shapes, faces, stick men, containers, call-outs, etc. That was fun, and it was similar to some of Angel's Drawing 101.
More advanced stuff can be found in learning to sketch on tumblr.

Closing keynote: Claudio Perrone on Popcorn Flow and A3 thinking

Claudio, a.k.a Agile Sensei, described his A3 thinking / problem solving system, and POPCORN flow, which is a kanban board for capturing, planning and tracking change experiments.
Slides here (well, very similar to the ones he actually used). Another interesting concept he described was "job to be done" (JTBD) as an alternative to user stories formulation, focusing on the human need you wish to fulfill. As an intro to the topic, Alan Klement's description of a "job story" is very useful.

There was much more, obviously, but that's what I can share. Great stuff, community!
You can find more here:

• Dror Helper's impressions of the conference here
• Gil Zilberfeld shares some stats (and a creepy photo holding Dalia's disembodied head)
• Twitter handle: #APIL15

Packing List for Your Agile Journey - Change

The Ten Speakers in the Series

Packing List

Today Gil Broza interviewed me about "embracing change", as the 9th interview out of ten hour long interviews in his series called: "Packing List for Your Agile Journey".
Subscribers get the ability to listen live or offline, access to transcripts. Gil asks each speaker to focus on one topic, so the overall series has a great balance of topics for listeners who want advice and ideas for starting or improving an agile implementation.
The topics are: Organizational support, enabling collaboration, feedback loops, whole product thinking, quality, technical excellence, get-to-done mentality, culture, change and values.

Some of the Things We Talked About

Gil asked me about change - how agile helps you deal with change, what types of change do we deal with or worry about, how did we (and still do) change an organization to become agile?
Some of the insights I can now recall without having a transcript of the call:

• People don't really resist change. They resist change that's imposed or seem arbitrary.
• Agile is designed to deal with changes in what you do, and encourage you to change how you do the work. It's less prescriptive about how to change to agile, which is essentially a cultural change
• Understanding and buying into the values and principles of Agile is much more essential than mastering a specific practice or ritual. Going through the rituals mechanically is equivalent to a "cargo cult", and will yield very little improvement, if any.
• Working in a large and distributed organization such as Software AG, there were a few observations:
• Sometimes a cultural difference is felt more after a merger/acquisition, than across geography and nation
• The challenges include quick integration of products, organizational changes (due to M&A), and building and maintaining trust when people are in different locations and timezones
• Having a senior manager who "gets it" and can point the direction and set priorities is invaluable 
• We have a "Change Agents" team who represented all locations, got together and got deep coaching and continued to function as a virtual team. This team was very helpful quickly getting the whole organization to learn the principles and coach people to start experimenting with the process. It also helped building trust across locations.
• We invested much in values, culture, lean principles and teamwork training - more than any specific practice
• Push back if you feel you are about to do something dumb
• A Responsibility stance (Avery) or Being Proactive (Covey) is essential to successfully dealing with change 

I'm likely to update this page after having the transcript to maybe reflect the content a bit more accurately.

More Questions

I'll be happy to get comments on this post from anyone in the audience who'd like to expand on anything I mentioned or ask more.

Habit 2 - Begin with the End in Mind

This is a part of my Introduction to Covey's 7 Habits series.

“Life can only be understood backwards; but it must be lived forwards.”
Soren Kierdegarrd, 1843

Beginning with the End in Mind means...

Imagine you're dead.

Morbid, right? 
Still, imagine it, and imagine what you want people to say about you. It's not a vanity exercise, it's a way to help you reveal what you value as worthy goals to review. It also helps put the daily life busy-work in proportion. Does it really matter if you used every spare minutes doing a great job on some work that, in retrospect, didn't serve any greater good that you are proud of?

Before anything can be physically achieved, it is envisioned. Covey calls it "all things are created twice" - mental creation which precedes the physical creation. The point is, who drives your life? Do you envision your choices proactively, or do you let someone else lead your life?

Personal Leadership

While management is attributed by efficiency and "doing things right", leadership is about effectiveness and "doing the right things".
This Habit is about personal leadership - defining what you value as the right things. Using self awareness, imagination and our conscience we can build a Personal Mission Statement to aim our lives towards. This is a self defining action, building a sense of who you are and what is your role in life.

At the Center

What is the source of security, guidance, wisdom and power in your life?
Covey point various centers he observes people draw on: spouse, family, money, work, possessions, pleasure, friends or enemies, church or self. Putting such things at the center makes you dependent, and Covey points out the option (or, rather, need) of being centered on "correct principles" - deep, fundamental, unchanging truths. As such you try to stand apart of the emotional triggers of a situation and observe options, as described in the first Habit, Be Proactive.

Applications in Software Development Practices

While Covey talks of the ultimate end (death), there are also other ways to apply the same pattern to smaller scopes. Lean pull systems, Agile practices such as test first and even the way user stories are formulated all aim at starting with the required result, value, purpose - and work your way back to the tasks needed to realize this result.

Related Reading

I liked this post Life on Purpose: 15 questions to discover your Personal Mission which actually has a good list of further reading at the end of it.

Habit 5 - Seek First to Understand...Then to be Understood

This is a part of my Introduction to Covey's 7 Habits series.

"No one cares how much you know, until they know how much you care" ―  Theodore Roosevelt

Empathic Communication 

Like any good doctor, diagnose before you prescribe. We learn how to read, write and speak - but what about listening?

Image from a blog by ksa

Most people listen with the intent to reply. They have two modes: 'speak' and 'prepare to speak'. Even when we do listen, our basic instinct is to apply what people tell us on our own experience and biography. "oh, I know exactly what you mean!". When we do that we've stopped hearing. Empathic listening is about understanding others from their frame of reference:

"You never really understand a person until you consider things from his point of view... Until you climb inside of his skin and walk around in it.” ― Harper Lee, To Kill a Mockingbird

Levels of Listening

Try to identify at what level you listen to someone - at home or at work:

1. Ignore or pretend to listen 
2. Selective listening (scanning for key words of your interest)
3. Attentive - focus on the words
4. Empathic - listen to what's being said, and the underlying emotions

Empathy is about understanding emotionally. Don't confuse Empathy with Sympathy. Sympathy implies agreement and judgement.

Emotional Bank Accounts

Covey uses the term "emotional bank account" to describe the ever changing level of trust between two people. The very process of empathic listening is an Emotional Deposit - it fulfills a basic need of being understood, appreciated, affirmed. This is building up the ability, trust and good will to work together (interdependence).

Empathy is Risky and Hard - It's for True Pros

Risky because you really open up to be influenced. You put aside your own agenda and seek to understand.
Hard - it is easier to draw on "what worked for me".
It's the mark of professionals - A doctor (diagnoses before prescribing), A salesman (Solutions, not products).
We tend to evaluate, probe, advise and interpret from our frame of reference. 

To understand we need the combination of: 

• a desire to understand
• strength of character
• positive emotional bank account
• Emphatic Listening Skill

Steps to develop the skill:

1. Mimic content you hear, reflect. Show you heard and pay attention
2. Rephrase what you hear (apply thinking)
3. Reflect feeling ("you're feeling...")
4. Rephrase and reflect feeling - build trust to open up

Apply it whenever it gets emotional. Help the speaker reflect on his words, rephrase, change their mind..

...Then, seek to be Understood

Covey defines Maturity as the balance between courage and consideration. After applying consideration by truly listening, it's time to courageously communicate what you have to say. 
Ethos, Pathos and Logos are the building blocks of an effective presentation:

• Ethos: your credibility, emotional bank account
• Pathos: emotional alignment, empathy
• Logos: logic and reasoning

This means, aiming at the context of your audience, at their frame of reference. By doing this you might learn and change the content of your presentation (that was the "risk" when you listen - you might just learn something!)

And here is the long term benefit, and why you may want to apply this with your family: 
The more you understand someone - the more you appreciate them and experience meaningful connection.

Related reading

Nonviolent Communication by Marshall B. Rosenberg

McCarthy's core protocols: Investigate

Software AG at Agile India 2014

On January 2013 I had the great experience of sharing in Israel some of what we learned at Software AG during our ongoing road to Lean and Agile, and I know of a couple of other colleagues who presented at other conferences.

Last week, Bangalore hosted the Agile India 2014 conference. Four days packed with speakers from all over India, and many international speakers. This time, my colleague Harish Krishnaswamy was presenting a very different perspective of our story. You can find the slides here, or read the full experience report which is packed with information and inspiring data of the significant impact of the transformation. I recommend to people interested in large scale transformations - read the report. Harish did a great job collecting information and interviewing many people in different roles regarding the journey. I'm sure people of Software AG would find it interesting to read a story they played a role in from a different, more holistic perspective.

An impressive amount of four more Software AG employees gave lightning talks: Amit Deshpande, Heartin Jacob, Chandan Ravishankar and Ramya Gopalakrishnan.

Amit spoke of Scrumban, a combination of Scrum and Kanban which can be used in those circumstances where you have a mix of feature development and technical debt/customer issues. In particular customer issues or unplanned events that could be disruptive to the planned work in a sprint.

Heartin blogged on the topic of his talk: what success means in Agile and how Agile helps us to be successful, highlighting the strong bond linking technical and organizational success with the personal success of individual contributors. 

Chandan asked why are you following Agile? The key point is that following the practices becomes an empty shell without being a part of the transition, caring and having personal engagement with the work you do (aligned with Heartin's theme). Another is the point that agile practices are designed to keep you honest about what you can deliver on a sustainable pace, and encourage you to aim higher based on the current reality and your history.

Ramya talked of using WIP limits to reduce Context Switching, sharing the specific context and behaviors the team adopted to deal with complexity, reduce stress and maximize learning and collaboration. I'm not sure how common it is to do an exercise with the audience demonstrating context switching in a five minute lightning talk and still have time to say something - wow!

Such evidence strengthens my belief that the transformation we're going through at Software AG runs deep - many individuals align with it and contribute well beyond their job description for the success of the organization, for technical excellence and in support of their own growth.

Agile Practitioners 2014 Conference Impressions

I know Lior, Elad and Ilan, a.k.a. Practical Agile, for a while now. I had the opportunity to speak in the Agile users group they organize (and attends sessions) and also to speak on last year's conference. There were also workshops and other activities, including the unforgettable Coach Retreat Tel Aviv with Yves Hanoulle. 

Board Exhibition

This year's Agile Practitioners conference had 3 tracks to choose sessions from, other than the key notes. 

The venue was a good match to the needs. I liked the exhibition of team boards arranged by Amit Yedidia. I also liked the feedback green boxes and the feedback notes: they were small enough to make you give short comments, and it was phrased to get positive comments and things to improve.

Keynote by Jutta Eckstein

Jutta Eckstein gave the opening keynote, "Towards a learning organization". She started with her view on the origins of agile: Toyota, the SmallTalk community and Patterns (architecture and process) and identified a shift in application focus from smaller teams to larger and distributed organizations, and extending outside software development over time. 

Jutta Ecktein's key note

Different adoption strategies hold different risks. Specifically, top-down approaches tend to rely on certifications, which may ensure some knowledge but come short on developing skills, performance and the mindset of continuous learning. Think of a diving master who'd be allowed to guide before ever getting wet. A better option is to follow the famous Shu-Ha-Ri approach as coined by Cockburn.

What organizations need to understand going agile is that it is a cultural change. HR can support this change as a personal development initiative towards more personal responsibility. Performance evaluation and MBO plans will need to change to prefer team achievement over personal goals. Managers need to serve as role models for learning, for allowing failures and admitting their own mistakes.

See also: cool sketch of this talk by Angel Medinilla.

Project Retrospectives

Next I attended Naama Gafni Lifshitz who shared her insights about hosting Project Retrospectives. She had a bunch of very useful, practical tips and structure. Great stuff on how to prepare, who to open, gather input in groups, cluster it all (with pre-thought-of color coding!) and prioritize, investigate for root causes and potential solutions and how to wrap it all up. Look for the slides once they are public if you plan for such a retro to get the tips - and pitfalls to beware of.

Developing Great Scrum Masters

Angel Medinilla is about to brag

Angel Medinilla (@angel_m) gave a funny and energetic session, identifying the limited amount of guidance scrum masters have regarding their role and offering help with a few archetypes: the go-through-the-motions "Scrum Dude", the over protective "Scrum Mom", and "Yoda" the facilitator, true scrum master, who grows the team, teaches how to deal with conflict and delegates progressively (self organization is not a boolean attribute...). Next comes the hypothetical "Agile Nirvana", the scrum master who inspires agility by his/her very presence.

To be effective, the scrum master needs to be one step ahead of the team on this continuum - the delegation oriented Yoda will get blank stares from the beginner team who's used to the Dude. Get them a Mom.
To develop great scrum master, you'll need to acknowledge they need to combine technical understanding, human skills and agile knowledge. based on the current skills, invest in learning to get a balanced mix of capabilities.

Ready, Steady - Sprint!

Avi Naparstek, Shirly Harel Ronen and Dan Kuida hosted a card game, which was aimed to get the players familiar with various agile practices and which problems they can address. The short session wasn't enough to get the full set of rules across, so playing was somewhat chaotic - but at least some of the concepts came across nicely and the atmosphere was playful. The cards were beautifully designed and executed, and with more time I'm sure the game can come in as a fun and useful educational experience.
Here's a full report of it with many more details by Avi.

Uri Nativ - Stop Optimizing Start Simplifying

Uri's talk focused on efficiency vs. effectiveness, against the old-school management concept of maximizing utilization and "correct" assignment per expertise. Focus on results, on delivery, on velocity.
Another management pattern to avoid is making KPIs the goal. KPIs are useful indicators, but they must come with human judgement and feeling. Can't truly measure some things such as productivity or technical debt. Here are the slides.

Oren Ellenbogen - 5 leadership hacks for building great teams

Oren shared some insights and ideas he came up with after taking on a management role. I liked many of the ideas - applying a system of "code review" to management decisions, how to welcome new employees in a personal memorable way, how to recognize team members, how to embrace simplicity and how not to let HR have all the fun congratulating people for birthdays and such, taking out the personal connection. I loved that he called it "stop outsourcing your emotions".

Mike Vizdos - using scrum  and lean startup 

Angel did such a great job with the sketch I really have nothing to add: Another great sketch by Angel Medinilla.


As there were three tracks I know I missed some great talks, but that's life. Again, another great conference, and I've yet to write of the other events that came along with this. Well done, folks!
More on the twitter tag #APIL14