Page 5

Why would you automate, in testing, anything?

If with the word “everything” it was, for me, like an exacerbation regarding automation well with the word “anything” is something else.

Initially I thought that “anything” word is problematic because it seemed like absolute word which ignores context. But actually – I had to stay and think about it for 2 months – it might open the perspective of making sense of the multi-ontologies. It invites to dig more. Is like putting under the question why bother to try to automate something and because of this, in a way, it points into a direction to take context into consideration. Context which is situational, relational, temporal, …

Why would you automate, in testing, everything?

A bit of context: I was trying to answer a question Michael Bolton put on the Rapid Software Testing Slack chat group, the question was “Why would you automate anything?”. Yes, it was the word “anything” not the word “everything”. In trying to respond to the original question I answered also to the question from the title of this post. In my head was a mixture of those two different words, strange…

Below are several reasons I spot it about why is this desire to automate, well to automate everything :

– some managers does not have a clue what professional testing is ( by professional testing I mean Rapid Software Testing a Context Driven Methodology). The managers still think of it in manufacturing terms(” automate as much as we can”). And because of this then they want a way to speed up things. They see testing as tangible stuff. When I say management, I’m not referring only at the first level, but at all levels in an IT company;

– some testers who are not aware of their profession. Is a trend now with (using) tools, who encourage this. It seems the marketing promoting the tools is doing a good job. And novices (we should not confuse years worked with years of experience) think this is the way. Then with the help of uninformed management we arrive at the desire to automate everything. Somehow these testers are not aware of the misinformation they are doing, is not an intentional thing;

– some testers who see the trend( the dominant thinking) and for their personal advantage go on this path. They don’t care about the interest of the project. This is sick and a unprofessional behaviour which I witnessed several times;

– some programmers who are ignorant of what a tester really does. They think, because of their arrogance, that are too smart to need a tester or to respect him/her. For me this enters in the unprofessionalism behaviour;

– some programmers with good intentions seeing the benefit in automation but trying to make a general rule without having other thoughts. For sure these are not senior/advanced developers. I say this because a real senior/advanced developer knows the plethora of the possible problems and they shut up and think, holistically, before speaking/making a decision;

– a teacher/mentor/manager making their people to think about what it means to automate everything. I can extend here the idea that a tester/programer might do this do investigate/search/discover more about this topic.

Being agile without noise

This evening I remembered how I begun to work and how I made sense of agile. These vivid memories appeared because I saw a person with whom I worked in those days.

I don’t recall, while working there, the word “agile” being pronounced. It was one year and a half after the agile manifesto was signed. I remember now that I saw on the company’s site a page with text and a nice simple image describing the agile stuff, but in a personalized way! I was searching the web site of the company not because I was being told to do it, but because I was curious of what was on their site.

There, in those days, in the day to day work, in a discussion you would have not heard remarques like:

“we are agile”;
“we do scrum”;
“I am a scrum master”;
“I am an agile coach”;
“As a scrum master or agile coach I would…”;
“this is not agile”;
“this is waterfall”;
“ yes we are agile … we have sprints”;
….
The person I speak about, I think is one of the best professionals I have worked with. I tried to imagine his response on the question “Do you work agile?” or something similar. I think it would have been like asking Morihei Ueshiba if he knows about martial arts. I think his response would have been a smile. A smile letting you know that you started with the wrong question.

At that moment in that firm there were 3 persons like him. These professionals were complete, if I can say so – they were the top of the seniors: good programming skills and knowledge, mentorship, working with requirements, working with the client directly, handling people,… — they were one of a kind.

I saw this guy handling in one day: ColdFusion, C# and C++. And it was so natural to him. I said C# because I went to him with my work which was bad. He asked me “Why did you do it like this?”. I tried to give him an explanation and I remembered he said stuff, but he saw hesitation/doubt/lack of knowledge/stupidity in me. He took the keyboard and begun to work in my code. He was, in that moment, in a lot of pressure because he had other stuff to finish. I was so impressed on how he begun to program and explain. It was guiding with facts/attitude not just words or platitudes.

You would have gone to these guys and you could have not tricked them with a simple discourse/speach or induce them in error with charm or platitudes.

For them was so natural to be in that spirit. They made no hassle about it. It was like it was written in the manifesto and I did not had the sensation of rigidity in the approaches we made at that time. We made daily and I did not realize I made daily, it was so natural…

I am glad and so lucky that I understood from them how…well you got it.

Conclusion: I think Jerry Weinberg was right when he said that “Agile methods will be successful if and when we stop seeing them as anything other than normal, sensible, professional methods of developing software.”(1)

◎ Image from http://alistair.cockburn.us/Shu+Ha+Ri

(1) Gerald M. Weinberg, “Agile impressions”, https://leanpub.com/jerrysblog

What a Scrum Master should or should not do

In my circles, I see lots of confusions/discussions regarding what a SM should or should not do. I already wrote before about the need of a SM for a project. Sometimes I feel this role is trivialized, that is being used as excuses of not doing things.

“Most arguments seem to be about conclusions, when they’re really about premises”(1) . So the premises:

● Beside the role as a SM or PO, it might happen that the organization will consider the SM or PO also in a position of middle management (PM, TL). But the discourse regarding PM/TL is changed a little bit: The PM/TL has to take care the project is OK, whatever that would mean…

This might contradict the Scrum thinking/philosophy, but this is another story. The idea is that we have to deal with this reality and acknowledge it.

● The Scrum Guide describes SM relation with PO, team and the organization. The Scrum guide might seem simple, but actually I feel it as a rather exceptional condensation of a lot of information. Take for example just the word “facilitation”, I think days can be spent only on treating and understanding this word.

I have some, let’s say, rhetorical questions:

– Shouldn’t a, good, really good, not mediocre, SM understand PO work in order to help him? By this I mean, maybe, to acquire skills of PO. The better the SM understand the PO, the better SM he becomes because he’ll be able to be more helpful for PO (and subsequently for the team);

– Should the SM help the team by removing impediments and creating high value products only by ‘organization means’ and by encouraging them(being supportive)? Where is his personal touch? By ‘organizational means’ I mean that the organization should help the SM no matter the problem, of course via standard tools/ways of working to solve the problems. SM should be creative, be autonomous and adapt solutions to the specificity of each project.

How the SM will really coach the team in self organizing and cross functionality if it does not participate in the current work? Should encouraging with platitudes be enough? Bringing others to do it? Hmmm….Maybe encouraging without facts and actions will have a small impact.

What I want to say is that, maybe maybe, we need to consider that a SM should be also technical. By technical I mean a developer or a tester(I belong to the Rapid Software Testing testing school just to be clear what I mean by tester) or …, so she/he can take info not only from others(like horoscope) and numbers(we are mature people still)(4). I think I would phrase it more generally that they should be with the “skin in the game”.

Yes is possible to have the non-technical SM…but…but…this will be helpful, for SM, as rather than rely entirely on the input of the others, SM will be able to make his/her own assessment based on his/her experience and validate it and not take it for granted.

I saw that in delicate situations where a project must be saved a good multi-skilled SM is being put into play, when the others kind of SM are being let aside maybe because is safer…

I feel there is a tendency to put as SM people with no or little experience/knowledge but with good discourse…. – that’s why I am tough! I try to imagine a surgery team in a hospital organized by Scrum, then the SM for that surgery can be the physiotherapist? Just to be clear: Scrum is good, but in the proper boundary.

● Tuckman model(*) of team formation and development. The situational leadership model is changing depending on the stage the team currently is in. So it might be directing or coaching or supporting or delegating. So within the same Scrum team the tactics of SM might or should change.

● Last, but not least, I think is imperiously needed to be aware of the “multi-ontology sense making”(2). I like that this invites us to transcend the type of system we are in. Scrum, in Cynefin(3) parlance, is at the boundary between complex and complicated. But a dynamic of project/situation will not always stay in a certain type of system. What if suddenly from complicated the type of the situation will change between chaos and complex. What should a SM do? Stay and use the techniques/tactics for which Scrum is designed? Shouldn’t try to adapt and consider the appropriate techniques/tactics/measures of action for the corresponding type of system? Ok, it will no longer be SM by the book, so?

So, I hope to see more SM’s:

○ who are very well prepared;

○ that stop using platitudes;

○ that know about Nonaka work ( even if they my not agree with some of his work );

○ who know the work of Jim Coplien (dailys are his idea/inspiration from Scrum; and the technical book he wrote “Lean Architecture: for Agile Software Development” is great);

○ who stop trying to be pseudo-psychologists;

○ who understand that to be a coach/mentor requires preparation, lot of it;

○ who understand that agile does not equal Scrum;

○ who dare to ‘dirty’ her/his hands and to help the team by working effectively in the project, of course, making use of the skills they have when she/he thinks that the benefits of this action are bigger than the possible disruptions;

○ who will have no problem to let another one be SM and she/he be a simple member of the development team, at least temporary;

○ who will realize that she/he is Master not after a few days of training, but after years and years of work and preparation;

○ who understand the job of a developer and the job of a tester, and then realize that you cannot switch one with another with the excuse of self-organization;

I know there are other schools of thought and is ok. I accept their opinion, but this does not imply that I also agree with them. Context matters a lot.

(*)Update February 27, 2018:

I indicated Tuckman model because in the agile world is a very known model. My intention was to show that a team is not in a single state at all, but on the contrary.

I reviewed the original paper where Tuckman wrote about this. Actually this model is not proven. In the initial paper “Developmental Sequence in Small groups”(5) he reviewed the existing literature regarding “dealing with developmental sequence in small groups” and he suggested “fruitful areas for further research”. So is a “statement suggested by data presented and subject to further test”.

Ten years after the original paper was published another one was published, “Stages of Small-Group Development Revisited”(6), in order “to examine published research on small-group development done in the last ten years that would constitute an empirical test of Tuckman’s hypothesis”. In the conclusion is stated that “It is noteworthy that since 1965 there have been few studies that report empirical data concerning these stages of group development…There is a need to supply statistical evidence as to the usefulness and applicability of the various models suggested in the literature”

(1) Michael Bolton, “Testing, Checking, and Changing the Language”: http://www.developsense.com/blog/2009/09/testing-checking-and-changing-language/

(2) Dave Snowden, “Multi-ontology sense making; a new simplicity in decision making“ http://cognitive-edge.com/articles/multi-ontology-sense-making-a-new-simplicity-in-decision-making/

(3) Dave Snowden, Mary E. Boone, “A Leader’s Framework for Decision Making” https://hbr.org/2007/11/a-leaders-framework-for-decision-making

(4) James Bach, “No KPIs: Use Discussion”, see comments, http://www.satisfice.com/blog/archives/1440

(5) Bruce W. Tuckman, “Developmental Sequence in Small Groups”, http://dennislearningcenter.osu.edu/files/2014/08/GROUP-DEV-ARTICLE.pdf

(6) Bruce W. Tuckman Mary Ann Jensen, “Stages of Small-Group Development Revisted”, http://openvce.net/sites/default/files/Tuckman1965DevelopmentalSequence.pdf

Incapable to defend real testing

I am a developer, also a Team Lead. I remember now the moment when I realized that if I’m a better developer is also because of the help of a good testers. Initially it was like a cognitive dissonance: how come a good tester help me be a better developer? Even stranger for me was that when I realised this, I was deep involved (still deep involved) with TDD, unit tests and Automated Acceptance Testing.

There are devs who think that if they do tdd/unit tests everything will be ok and testers will do “some clicks”. Or even worse, the testers, for those devs, should check all the nonsense made by a developer, because that developer will not test. So strange. So a developer should not experiment, learn, explore, investigate, find relevant information from his/her own work.

I am sad. I was unable today to defend the real craft of testing (Rapid Software Testing). In a way, I felt that I was not able to defend those testers who contributed to make me better professional. So strange feeling.

Then I begun to think more. Now is a lot of talk regarding “manual” testing and “automated” testing.

Note: I told to a marketing person that she is doing “manual” marketing. And this sound so strange almost like offending. I told her about testing and “manual” testing and she understood. Still I can’t forget that it almost sound offending.

Why do they say “manual” testing? Maybe because a tester should just verify a specification, no matter the form of that specification – wait, I am wrong, is a user story with acceptance criteria, of course. Since is a clear specification, it is imagined, I think, that they can also write what they will test – some will say they write the test…. Hmmm…So, if they can write it down this means they don’t need a tester with experience – may be temporary – , a junior should be enough because anyway acceptance criteria are done by the Product Owner. But if a junior can do it, then … wait we can automate those steps, yes, yes via UI. So, hmm, why not get rid also of the junior tester, because we have the automation which is the ultimate goal actually. A click of a button and that’s it. For sure that automation code will be developed not by experienced developers like it would be the production code, no, no we have “automation” testers.

So why a tester should matter so much when actually he/she is only doing some of the shallow testing a developer must do? Shallow and clear steps which can be done by anyone.

So, I imagine that’s why – briefly described – some testers are being called manual and automated.

If testers spend time on shallow bugs they will not have time to see for deeper ones. Such deep that neither a dev can’t see it.

But what do those testers that I was not capable to defend? They, although they might not phrase it like this: investigate, doubts, searching for information, pose questions, questions everything, do more than confirm acceptance criteria, they challenge the actual criteria, they make definition of done/ready relative when all the other thinks are clear and absolute, are able to begin testing without specifications if needed, be able to show the multidimensionality of a problem/specification/story, use any tools which can help them (not just selenium or…), they will not answer to different problems with same answer because they are aware of context, support developers, …. please see here for a much longer list: http://www.developsense.com/blog/2017/04/deeper-testing-2-automating-the-testing/

Sorry colleagues testers :(.

Managing technical debt discussion

Shu(1): We found a way to manage technical debt on the projects. I’m curious what you think about it.

Ri: Tell me more. How did this topic arise? Why was your team affected by this?

Shu: Well, it was a top down decision. So we have to manage it somehow. And for doing so we have to see where we are.

Ri: So you don’t know why. The fact that it’s a top down decision doesn’t mean you know the answer to the “why” question. So you are affected because you all have to do it. Hmm…ok. Why do you say “we have to see where we are”?

Shu: By “we have to see where we are” I mean that we need some numbers, like those provided by Sonar.

Ri: Numbers? Don’t you already know how your project stands from a technical point of view?

Shu: Hmm…I don’t understand what you’re trying to say. This is what I was told to do.

Ri: Don’t you participate actively in the day to day work of the project? Aren’t you capable to articulate some aspects?

Shu: Well…yes.

Ri: So why are you acting childishly?

Shu: Childishly?

Ri: Yes. Why do you think complex and complicated stuff can be reduced to numbers? I understand that parents need to make things simple for their kids but you are an adult … you should be able to handle complexity and complicated stuff. (2)

Shu: Why do you think numbers are not ok?

Ri: I didn’t say that. I said that it’s not ok to reduce such an important topic to a simple number.

Shu: Well… then how do you know you are ok from a technical point of view?

Ri: Is technical debt actually a technical problem?

Shu: Ha?

Ri: Ok. Let’s take an example regarding numbers. You have a module 1 which was not modified for years, some of the code is actually generated and it has lots of warnings. What do you do? What do those numbers regarding the module 1 tell you, compared with another module 2 which was modified 5 times in the last 2 sprints? In the end, Sonar tells you that you have 500 days of technical debt. So what will you do about that?

Shu: I will want everything to be cleaned up.

Ri: Why?

Shu: Because clean code matters.

Ri: Don’t deviate. Don’t tell me platitudes. What we are talking about here is how you interpret those numbers and how your actions are guided by them.

Shu: I think that, maybe, we should handle module 2 issues first, and then module 1 issues.

Ri: So what do those 500 days mean?

Shu: I don’t know.

Ri: Why not? It’s a clear number written there….

Shu: It seems that days representing module 2 are more important than days representing module 1.

Ri: Will it always be like this?

Shu: Hmmm….Now that you ask, I am tempted to say: no.

Ri: So, let’s go back to the question: what do those 500 days means?

Shu: I don’t know. At first sight it seemed clear but now it doesn’t anymore.

Ri: Good, you begun to think a little bit. So do you think that by seeing those numbers you can know where you are?

Shu: Nope.

Ri: Why not? At least now you have something. Initially, it seemed, you had nothing.

Shu: Hmmm…actually I did had something….by participating in the work that was done, I saw: the code, automated checks, professionalism of the team members, how prepared the team members are, behaviour of writing code of the team members, bugs, issues, problems, testing. So in a way, tools like Sonar help a little bit by providing a perspective, but to say that they are the key point in managing technical debt is not ok. So tools like Sonar continue the list I mentioned above?

Ri: There is one point I wish you would have mentioned. How do you know, by looking at the code, what problems it had?

Shu: I have to see the history of the code. A lot of information lies in source control. Information which has to be analyzed and interpreted according to context.

Ri: So technical debt is only a technical problem which can be tracked/simplified by some numbers shown to the upper management..numbers which occasionally are stripped out from context?

Shu: Nope… A lot of discussions have to take place, based on the unfolded details.(2)

Ri: Let me come back to the beginning, and ask: why did top management impose this?

Shu: Hmm. I think I know the answer but I can’t articulate it.

Ri: You just mentioned a long list of dimensions when managing technical debt. Are all people managing the projects aware of those dimensions?

Shu: No.

Ri: What should top management do in this case?

Shu: Impose, so things won’t go in the wrong direction.

Ri: Yes, but why?

Shu: Lack of trust? I believe they thought that having Sonar as a common denominator for all projects was a way to at least control the complexity and mediocracy of the people managing the projects. Mediocrity which in the end affects the dynamics of the project a lot, and which creates a space also for technical problems to flourish.

(1) Alistair Cockburn, “Shu Ha Ri”: http://alistair.cockburn.us/Shu+Ha+Ri

(2) James Bach, No KPIs: Use Discussion: http://www.satisfice.com/blog/archives/1440

Regarding Technical Debt Quadrants

I like the way Martin Fowler(1) tried to classify Technical Debt. I think it was a way to show,in a simple not simplistic way, how to grasp the complex nature of what technical debt actually means and how to handle it. I intentionally said complex not complicated.

So, technical debt might appear easier to grasp ( especially due to code analysis tools) but maybe it’s not like that. It seems that we have to rely on the sapience of developers, and I would say testers(2) as well, to take care of the code.

Below are some short thoughts regarding quadrant elements:

– reckless vs prudent for inadvertent: I connected it with the training/qualification of developer(s);

– reckless inadvertent: it seems that (some) basic notions of oop/design/architecture/… are missing;

– prudent inadvertent: we might deal with good developer(s) who had an “aha” moment. In this case, the simple fact that they realized something is a good thing, it’s a sign of progress;

– reckless deliberate: it’s a clear intention for “quick and dirty”. This might be ok in a certain moment because this decision is intentional and fully aware of the context. And it is known that it will be taken care of.

But I usually see this “quick and dirty” solutions from so called senior developers who are unprofessional. For example, these unprofessional devs:

preach that they want clean code and assure their team members that they want to do it, but behind closed doors they are doing actions( technical work) to impede this;
are happy to do some small checks/verifications/investigations which requires no management approval but they ask for time allocation and for the management to agree. And they do this because they know they can sabotage the things so that in the end to do the “quick and dirty” way.

– Prudent deliberate, if applied ok (not by so called seniors mentioned above), might be a sign of holistic thought. It makes me think of the mantra: “First make it work, then make it right, then make it small and fast.”(3)

So, things are not so simple when speaking about technical debt. For those that are interested only in numbers I have a question: How many developers do you know that connect neuroscience, cognitive psychology, complexity theory and forensic psychology with how code is written?

(1) Martin Fowler, Technical Debt Quadrant: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

(2) Context Driven Testing: http://context-driven-testing.com

(3) Robert C. Martin, Test First: http://blog.cleancoder.com/uncle-bob/2013/09/23/Test-first.html

Faking the reduction of technical debt

I spoke before about multidimensionality of technical debt.

Unfortunately, sometimes, “Reducing Technical Debt” is used as dust in the eyes. It’s not that obvious when we also use tools for “Reducing Technical Debt”(like Sonar, Ndepend,….). I mean who can contradict the efforts in reducing the technical debt when the people doing it also use tools and can show some numbers? If some non-sense warnings are also solved to decrease the numbers…wow.. they are really attacking the technical debt.

Maybe the real test in showing that work is being done in reducing the technical debt, is when some important technical problem must be solved. But because of strange forces it doesn’t get solved. I’m speaking about that kind of problem which will help in lots of directions( including financially!!). That kind of problem which is a pain for years and years but it is never touched.

Why won’t this problem be solved? Probably because the current situation is more comfortable for the people that should take care of it. The present situation is easier, the status quo is known, as well as how to react in it. Perhaps the desire to reduce the technical debt isn’t real in the first place, and the work is done just for show, just to follow the trend. Or maybe because we simply don’t have too many scrum masters/PO’s/managers that actually understand how software is build…..

Some perverse/strange/sick situations arise when dealing with reducing the technical debt, especially when this is imposed. These situations on the surface might seem to be ok but below the surface might be a total mess. A mess that’s hard to detect if you’re not looking at the code, but instead, just analyzing some numbers generated by the tools.

Technical Debt in relation to Business Features/Roadmap

The technical debt subject, especially in relation to business features/roadmap, continues to pop up. Sometimes I have the feeling that certain people (especially managers) lack some understanding of certain dimensions which should probably be considered in regard to this subject. So, below, there are some points to consider when thinking about technical debt concept and also its relationship with business features/roadmap:

Dualism: There is a strong emphasis on a dualistic way of approaching things. In a way it’s understandable, it goes back to cartesian dualism. Dualistic categories in which one side is right and the other, probably wrong. In this case business and technical debt are thought of as being dual. Technical debt, if approached with pragmatism, helps improve the cycle time; but pragmatism requires knowledge. So actually if we speak with Business People/PO/…, they should think in terms of “business features” and “business cycle time.”(1)

Note: I have said knowledge. With technical debt, unfortunately, the trending words are now tool names (like Sonar). The tools are good, but they must be used wisely.

2.”Quality is a statement about some person(s)”(2):

Let’s not forget about the fact that the decisions of PO’s/SM’s/Architects/Developers might appear rational but in fact those decisions are emotional and political. For example:

– a PO might be too afraid to impact the release;

– the work of an architect might be put away or delayed or he/she has to have an argue with someone – which is not in his/her interest;

– A developer may not want stress. It has other priorities/things to do;

All above examples might be understandable or not, it depends on the context. Still “quality is a statement about some person(s)” .

Technical Debt:

I think this is such a misunderstood concept. This word is used often and connected suddenly to tools. But tools only assist, and those tools should be used in a sapient way(3). There is much more to technical debt and it’s a sad thing that I see it trivialized and bastardized. So when I think of technical debt I think of: prudent deliberate technical debt, reckless deliberate technical debt, reckless inadvertent technical debt, prudent inadvertent technical debt and the history of this concept.(4)(5)(6)

Wrong metaphor regarding IT and code:

We think that when we apply measurements on the code, that it’s the same as in engineering. Well it’s not quite like this. When civil engineers do the measurements and planning, there is a clear way of what will be constructed, no false positives(7). It’s a complicated thing, meaning that there is a clear way between causes and effects. In software it’s not like that. What we have are only fuzzy things. Ok, we’ll repair all the warnings and errors spotted by the code analysis tools (Eg: FxCop/Code Analysis, Ndepend, Puma, Sonar, …). Then what? Will the software be ok? No, we do not have the same certainty as in engineering. There are lots of false positives and if the approach is not made carefully, holistic view might be lost.

So what’s the metaphor? Maybe it’s biology, ecology, medicine.

Note: Tools are ok. They help and extend human capabilities, but they are not a replacement for human judgment.

How can I show that the technical aspects are ok on the project? When I hear this question, at first glance, I do not have technicality in my head. I try to see the holistic view: social part (by the way architecture has a social component), release time, impact on testing, lost time, features delivered, responding fast enough to changes, capable to deliver innovative things fast enough that not even users know how to articulate or need…

So: Technical Debt or Business Feature/Roadmap? When this question is raised and a decision has to be made, for me it’s a heuristic that things are not considered, not even in the last responsible moment. Things didn’t happen in isolation and this means it’s a good moment to think about risks.(8)(9)

(1) Jim Highsmith, “Features or Quality? Selling Software Excellence to Business Partners”: http://jimhighsmith.com/features-or-quality-selling-software-excellence-to-business-partners/

(2) Jerry Weinberg, “Agile and the definition of quality”: http://secretsofconsulting.blogspot.ro/2012/09/agile-and-definition-of-quality.html?m=1

(3) James Bach, Sapient Processes: http://www.satisfice.com/blog/archives/99

(4) “Ward Explains Debt Metaphor”: http://wiki.c2.com/?WardExplainsDebtMetaphor

(5) Martin Fowler, “TechnicalDebtQuadrant”: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

(6) Michael “Doc” Norton, “Technical Debt”: https://cleancoders.com/videos/technical-debt

(7) Mark Seemann, Human Code: https://cleancoders.com/episode/humane-code-real-episode-1

(8) Michael “Doc” Norton, a phrase regarding technical debt: https://www.linkedin.com/feed/update/urn:li:activity:6338750195731353600

(9) Cory Flanigan post on LinkedIn and comment from Michael “Doc” Norton: https://www.linkedin.com/feed/update/urn:li:activity:6339019436988727296

Code review discussion

Ri: Do you make code reviews?(1)

Shu: Yes. Every time we make a commit we have to ask for two reviews. And reviewers must put a comment.

Ri:You are explaining to me the formal process, which should not be confused with the quality of the actual review. Why are you doing that?

Shu: aaaa, because we must do it. It is mandatory. No commits should be made without code reviews.

Ri: So, for example, you use it for knowledge sharing?

Shu: Yes yes,exactly

Ri: Do you trust the reviews?

Shu: Of course, I can show you no commit was done without them.

Ri: That’s not what I asked you.

Shu: Yes, I trust them

Ri: What level of experience do your team members have?

Shu: hmm.ughhh…confirmed(2-3 years of experience)

Ri: And they do the review between themselves?

Shu: Yes, of course.

Ri: Hmm, how can you trust those reviews and the technical quality of that code when, actually, the persons who made them doesn’t have that much experience in writing code?

(1) Alistair Cockburn, “Shu Ha Ri”: http://alistair.cockburn.us/Shu+Ha+Ri