Continuous Team Switching?

Douglas Squirrel led a session at CITCON Budapest 2012 about Continuous Rewriting, summarizing many ideas I've heard before from Dan North or Fred George presentations into a really coherent evolutionary progression, and took the concept even further.

Like other Continuous practices, this would be as much a technical as an organizational-cultural change. It got me thinking about how this would change the team dynamics - not just inside a team, but in the context of the bigger organization.

The various Continuous practices always came about the realization that when something is rarely done, people will be bad at it and thus it will be hard, ineffective and error prone. Thus if we simply do it more often, we would get better at it.

Joining a new team and becoming an effective contributor is a process that is in need of improvement (on most teams). Getting to grips with the inherent domain complexity and the piled on technical complexity, learning the tricks and workarounds, etc. can hold back someone from being efficient for quite a while. On the other hand, having a fresh set of eyes can provide a new perspective and expose much of the technical debt the team has.

All the continuous rewrite examples so far have reduced the code size, making it understandable (though often this reduction came thanks to better understanding of the domain).

Assuming the reduced code size enables speedier onboarding of new team members, while still benefiting from the new perspective it brings, what would more frequently rotating in and out rotation team members (while never completely replacing any one team) result in?

• Could this make spreading of ideas and practices within a company more effective and faster than the current silo'd, departmental setups?
• Would it speed up the on the job, just in time learning of every
  developer in the company?
• Would it improve the skill level of every developer, or would it drag everyone down?
• Would it strengthen the company culture, simply since each person would know more other employees (given that many of us only socialize within our own team)?
• Would it spark more cross-departmental improvements - unlike accountants or marketers, developers can jump between various areas and domains of the company with relative ease, and thus could see potential improvements. Would this make crazy IT processes (where the data passes through, without enhancement, several different teams and applications, modified effectively by only one at the middle, then be loaded back into the original source) extinct, making IT governance easier?

I don't know. But it certainly was a fun thought experiment! Feel free to add questions to the above list in the comments!

There Is More To Clean Code Than Clean Code

A post written by Uncle Bob in January (I'm behind my reading list) offended me. I absolutely agree with Uncle Bob's analysis regarding the code itself, and I also prefer the refactored version, but I have a problem with insulting the programmer(s) reluctant to appreciate the change.

We write code in programming languages, and there are different levels of proficiency in a language.

As I'm currently learning a new spoken language, I'm painfully aware of this - initially I probably sounded like a caveman. The first impression you get about me is totally different depending on the language I speak - but I am the same person!

The learning curve of a language is not smooth - the steepness between consecutive levels of proficiency is different. Going from not speaking any German to speaking A1 (tourist) level was easy, getting the basic grammar required for the low intermediate (B1) level wasn't too bad, but to get my German to the level where my English is will take more effort than the sum of all my previous investments¹.

Since it is my third foreign language I'm learning, I have no difficulty accepting that the level I think I speak is higher than the level I actually speak. Because of that, whenever someone rephrases my sentences in proper German ², I start from the assumption that likely their version is better, even if I don't understand first why - and I take the effort to understand their reasoning ³. I do that despite that I was of course convinced that when I spoke, I expressed my thoughts in the best possible way.

However, I don't have much at stake - no ego to hurt, no reputation to loose, and the roles are clear: I'm the beginner, and the people around me are the more experienced ones. In a software team, the roles might not be so clear - I had told colleagues almost twice my age how they should write code after only a few weeks of working there. Bad idea. Since then, I have learned not to start improving the coding style of a team by rewriting the code they have written, and showing off how much better my version is. Rather, I wait until a situation arises when they don't mind having me demonstrate some code improvements. I demo it, and explain why I do it that way. In my experience, the second approach is more effective, though it doesn't have that instant satisfaction and relief the first provides.

As the joke goes, you need only one psychologist to change a light bulb, but the light bulb has to want the change real bad.

Driving Technical Change is hard, because it requires a mental/cultural change, and that change has to come from the inside - but can be catalyzed from the outside of course⁴. But just forcing practices or ways of working on unwilling recipients generates resistance (e.g.: the story of the EU technocrat appointed to recalculate the 2009 Greek budget).

I would like to see more public code reviews and public refactorings (e.g.: Andrew Parker, GeePawHill), but I would like to see less public judgement passing on people at the lower proficiency levels of programming.

---

¹ there is a great Hanselminutes episode on learning a foreign language if interested. Beware, it may contain programming!

² German readers might disagree, since most Germans I meet speak Frankish :)

³ Which of course, is sometimes harder for natives to properly explain than for novices to ask questions pointing out the seeming irregularities of the grammar

⁴ And we won't always be able to foster change in all environments (note: this does not mean the others are at fault for not changing!). The same programmer can be highly productive in one team, and be the one slowing down another team. There is nothing wrong with changing jobs after realizing we are a net loss to a given team.

When in Rome, do as the Romans do

The Pragmatic Programmer gives a very popular advice: learn a new language every year. The main reason behind this advice is that when you learn a new language, you learn a new way to think.

However, especially when getting started with a new one, we (inadvertently) try to understand it by comparing it to something we already know, which is likely the language we are most comfortable with, thus turning the learning experience into a square peg-round hole problem. Be aware of of this limitation before dismissing a language or a language feature as something horrible.

Some easy to spot examples of mistakes I have seen myself and/or others make are:

• creating lots of simple DTO classes in Python instead of using tuples
• trying to create a synchronous API for a web service call in Flex
• creating an indexer for the immutable list in Scala
• ...
• ...and of course, procedural PL/SQL code with lot's of loops and ifs instead of set based operations

The subtle differences (idioms) can be trickier, but are worthy to learn about. Similar operations can behave surprisingly differently in different languages. When splitting a collection in C#, asking for an invalid slice range, you get an IndexOutOfRangeException, while in a functional language you likely get an empty list as the result. In Python it's called monkey patching, while ruby people call that opening up a class.

Even a seasoned programmer picking up a new language misses these - so if you can get someone to review your code in such detail as it's been done for Uncle Bob in Clojure or Davy Brion in Ruby, do yourself a favor, and ask for it!

If you are afraid of learning in public, and don't have access to experienced mentors, read code, and try to understand unreadable-at-first bits - I have fond memories of the time we have tried figuring out what (and why) some method did in scalacheck.

Note that I'm not saying you should not innovate, there have been (and will be!) great things coming out of concepts moving between platforms - boy I'm glad for NHibernate, and annotation based test methods coming from NUnit to JUnit were quite welcome too. However, first understand the platform's own means to the given end before deciding you need something from another platform.

So embrace the culture of the language, and if you feel you are not learning something new in the new language, don't rest, but seek out those differences that surely are there under the hood!

Happy learning, dear reader!