Working in a team where the policy is "never left any tech debt behind" it is surprising the amount of tech debt we already have accumulated. In fact, you can argue that what we are cleaning is not tech debt, but cruft code, I agree.

For the shake of this conversation, we are going to assume that such code is impossible to avoid entirely. So, if we always clean it before closing a user story, how can we have any of it.



Some of it is structural, decisions that have been made without taking the whole picture in mind, or inconsistencies between different parts of the code. The main suspect a lack of shared knowledge in a team where nobody being the glue.



The big part, however, is a consistent and deliberate application of YAGNI principle or at least a version of it. Fix cruft code and decisions is postponed because we are not sure about the implementation, the design or a mix of both.

A wrong interpretation from my point of view, YAGNI and make easy to change code must be complementary. What do you think?
References:
@cammerman -> https://twitter.com/cammerman/status/1511936610765619200 @kentbeck -> https://tidyfirst.substack.com/p/incentives-not-to-invest-in-structure


About technical debt

You know when a code is a bad code, you have a gut feeling, so you feel the necessity to critics that code and propose changes. Ok before doing that, let's do an exercise, why do those changes make the code any better?

Is it because you like it more and somehow that does it make better? Do you have any measurable argument that justify such a change? After a code review, the code is simpler because it is better or because you have more context?

I think we need a collection of properties we can use to express how good is a code.

I would say one thing that make a code better is understandability. Easier to understand, better the code. One property we can use is cognitive load,

if the cognitive load of a piece of code is under a threshold chances are that that code is easier to understand that one that surpass the limit. Does the code use language and team idioms? More idiomatic, the code is easier for the team to understand it.

The same happens with domain concepts, is the design influenced by domain concepts?

Another thing that could make a code better is how easy is to change that code. Here we can talk about coupling, and we can use connascence to compare one solution with another, removing subjectivity and personal preferences.

Dependencies are easy to count as well, fewer dependencies the better. I think we have some good tools to argue in a less dogmatic way, we only need to start using them. Which other do you think we can use?

Last episode of @progesunam remainded me that time when I asked someone about an offer they published on the slack of @VigoTechAllianc. In that time, I thought the best way I can help new people getting to this industry was making the questions they weren't able to make.

So, as this offer didn't include a salary range, I asked for it. The main excuses I received were these:

“The money is not a problem, we don't want to hire people for what money is so important.” — Well, money is important to me as long as I have to bring food to the table every day. I know what is my minimum, do you know what is your maximum?

If not, you should make some figures because if my minimum is very far from your maximum, we both can save a lot of time.

“We want to be flexible just in case the candidate doesn't suit the position, but we still are interested in hiring him.” — We developer understand these type of things, we can apply for a position and maybe the company offers a different one with a lower salary

and that is totally ok, what is no ok is to invest a lot of time to pass your selection process to finally discover that the amount of money you can pay me is not enough to make a life.

If you wonder how this discussion ended… The person that published the offer left the channel. The people in the channel started complaining because if we made this type of question, nobody was going to publish new offers.

The administrators allow me to stay on the channel but creating a new one to publish new offers where nobody can comment.

Pair programming is great, but only if you do it right. You can do it wrong and still get good things from this practice, but at the same it could be very frustrating. I start thinking on this after read some people complaining about it on Twitter.

Usually, the big problem to implement this kind of practices are far from the developer team.  However, in those tweet seemed to be something more. After practicing it steadily during 8 months,

I have discovered that it really brights when every peer take responsibility of different things. We developer use to handle a lot of complexity while we are coding,

if we add a second brain is to divide the cognitive load not to add more process power, human beings don't work on that way. In my opinion, this is the main lesson I have learned regarding pair programming because it really makes a remarkable difference.

Rest from time to time, and take time to think alone, is also useful. (This and more in the las episode of #ConsideredHarmful)

Keep changes small. I think there is a lot of misunderstanding about what a parallel change is and how to approach it, and some confusion when it comes to use it next to feature flags.

You don't need feature flags to do a parallel change, so if you feel you need them, that is a good symptom that you are doing something wrong.

Unlike feature flags that can last in time, parallel changes should be small and never should live more than a working session, the shorter, the better.

Do you have acceptance tests covering the old functionality?  Expand it, add unit test if required and contract.

Do you have test, but they should be modified? Extract functionality, add new tests for it, contract and delete duplicated tests.

To create software in small batches is hard. Progress taking small steps require finding the right increment and focus on reach it with the simpler solution. Sometimes I boycott myself, including more thing than those inside the scope.

There are a few reasons for that, but the main ones in my case are interruptions and coding alone. Interruptions destroy your concentration and focus.

The Mikado method can help to recover the context and the right path after interruptions. Two brains coding help us to maintain two different mindsets along the session and avoid the temptation of doing too much.

That and more today in #ConsideredHarmful!

Coding, sometimes, is like land a plane in the middle of the night in an unknown airstrip without lights. You know what you want, but you are going to discover how to do it at the same time you do it. It could be must easier if at least you have a light at the end of the airstrip

A driver is something like that, something that keep you in the right track in spite of the all the other problems you find during the landing.

Short feedback loops as TDD, linters, type systems are good examples of driver we can use to receive quick feedback and guidance during coding.

What is important is to use a driver as an assistance that make us aware of small mistakes/problems just after provoke them and to help us focus on the right thing.

However, sometime is not easy to find a driver, or maybe we can't see how to write a test that guide us. In those moments I use to step back and think is maybe the design is not the right one or if the level of abstraction where I am implemented this functionality isn't right.

In this talk, https://www.youtube.com/watch?v=SfWCRl75Kas&t=924s @DocOnDev says  that cruft code is the result of incompetence or a lack of professionalism.

But what is to be unprofessional or incompetent? How does it look?

When you start reducing the solution space, looking for feasible solutions that still provides the value is easy to cross the line.

So let's try to separate the solution itself from the implementation of that solution in our code.

We should start reducing the solution space to the minimum that solves our problem, but once you are there, can you somehow simplify the implementation without being unprofessional or incompetent?

If you leave behind obvious pending work probably that is incompetence, if you take shortcuts and does not track them as technical debt probably this is unprofessional.

We need to improve our skill to detect code not good enough as much as possible, and we need a framework to decide when to acquire technical debt, how to track it and when to pay it.

Context is key, but I have to admit that outside-in approach has worked better for me much of the times. Usually it associated to London approach since starting from outside requires to use some mocks to substitute the component you have not implemented yet.

However, my approach is different. Start from outside writing just enough code to make the test pass, paying attention to the API you are exposing and less on the internal implementation.

Once you have covered the behavior you want to implement, you can move inside to put some design and adding tests if required. Thoughts?