Software Architect 2013 Day #1

The Coaching Architect

Roy Osherove presented "The Coaching Architect". If you want a better idea of the manifesto, read Notes to a Software Team Leader, it's a great book!

Roy asserts that your role as a "Software Architect" / team leader / leader of any kind is to grow the team to solve problems on their own. Far from making you redundant, this makes you a highly valued employee; by growing others, you'll always be wanted. Unfortunately, this means stepping outside your comfort zone and dealing with people.

Many managers like to take the money, but not do all the hard parts (Gerald Weinberg)

Learning something new is tough. Everything you learn has a downslope initially. You lose productivity, it's hard. However, once that thing has clicked, your performance rises. This pattern never ends!

I've seen this behaviour before in Programming Epiphanies. Initially I'll try a new technique or language (let's say when I first found C++ and objects). I was terrible; I constructed code at work that made me cry the next day I read it. Eventually things started to get better. I had my code critiqued by clever people (I say critiqued, I mean brutally torn apart) and rewrote it and practised it some more. Eventually, I felt as if I was a C++ ninja and I finally got the language. A few years later and I felt pretty comfortable. Until, Alexandrescu wrote Modern C++ and it felt like throwing myself off the cliff again!

Roy argues that to grow your team, you should push them off this cliff and challenge them. You need some risk to learn a new technology. Learning a framework is your spare time is not a risk; learning a new framework on the job? That takes some balls. Pushing people to learn also is a risky thing, but to grow the team we must first realize that we can put ourselves in that scary place and grow

There's a time and a place for learning. Roy outlines three phases on a team of development and a suitable stance for a leader to take on each part.

• Survival - Teams are fire-fighting at this stage. Chaos rules! There's no time for learning. Teams in this mode need to get out of it, and the best way to do this is "Command and Control". Prioritize the tasks, use a clean slate and exit into the next mode.
  
• Learning - Teams in this mode have time to learn new techniques. Roy asserts that teams in this mode might go 300-400% slower whilst they learn a new skill (say TDD). As a leader on a team like this, your role is to support the team through coaching.
  
• Self Organizing - The team doesn't need you. They can solve problems on their own. Roy estimates that fewer than 10% of software teams find themselves in this place.

Teams get addicted to survival mode. Faced with the "write it now and get it out" or "test it" choice, teams often pick the former and get away with it. It feels good. It's only later when we realize we have to do a rewrite that we realize the folly of this decision.

It's OK, I hear you "lean" people. It's a waste doing it right, surely? It's an MVP man. What's the point in testing it if I'm going to throw it away? That'd be fine if you did throw it away, but you don't. We also overestimate how long we can get away with poor quality code. The design stamina hypothesis doesn't label the time axis, but in my opinion it's probably days or weeks not months or years.

Anyway. In order to break survival addiction, it's up to us as developers to take this under control. Give realistic estimations that build in time for doing it to an proper level of quality (you want to write unit tests? Make sure your estimate includes time for that, don't show it as a separate activity).

In order to understand why people don't change, Roy recommend the book Influencer: The Power to change everything.

For each behaviour, the world is perfectly designed for that to happen

In order to change behaviours, we need to understand the personal, social and environmental conditions that led for that behaviour to happen.

Roy ended up with a song. Which was weird. But was good.

Implementing micro-service architecture

Fred George gave an awesome presentation on micro-service architectures. He started with a brief history lesson of how he got to the plan of microservices, showing how his career had progressed from big monolithic applications through to service-oriented architecture. Each time he felt there was a collection of smaller things trying to get out, until one day he had the chance to try something crazy with a desparate team.

What if we built our applications as many tiny services, each fewer than 100 lines of code? Each service is like a class, a small and crisp conceptualization. Each service has a segregated database and encapsulates that information. Services publish conclusions; not raw data. This brings up some really interesting questions. How do you monitor systems like this? How do you keep it running?

The slides are available and I'd encourage you take a read. It's full of dangerous ideas. Why'd we need unit tests if we are just writing 100 lines of code? Why should we adopt a uniform language when we could just rewrite servers anyway? Why do we need to worry about copy-and-paste code?

I don't necessarily agree with everything (because I've never been involved in a system like this, and I'm a sceptical kind of guy), but it's great to see something different that challenges the way you think.

Architecture in the age of Agile

Rob Smallshire talked to us about architecture in the age of agile.

Lean thinking (I should read The Goal) says that it's all about the flow, and we should reduce our batch size to reduce waste. TDD does a great job of reducing batch size. You get feedback quicker and you find defects earlier. Rob argues that architecture is a counterpart to this; it helps you find defects in your system design earlier, it just works on a different time-scale.

A calendar and a clock also work on a different time scale, but we view these as complementary; not competing.

Architecture is about maximizing our ability to keep working sprint after sprint. Without architecture, how will you ever reach 200 sprints? Scrum is feature driven. I have a backlog of features which I rapidly complete, I throw them into a system and non-functional requirements are emergent properties.

This really clicked for me. In teams I've worked on cross-cutting concerns (performance, usability) often get neglected in scrum. We try to make features out of them, but that never works (how do you estimate "improve performance?"), so they instead get added to the bug tracker, usually split out into lots of little bugs (performance in history pane is too slow, performance on dialog x is too slow). The solution to these is not a local optimization; we should be considering the system and solving it from that perspective.

Rob presented some scary statistics on the half-life of code and developers on systems. On average on any project after about 3 years, 50% of the developers will have left. However, the code often lasts longer than that.

As architects, we should take that into account. Deliberate design provides context and structure and, most importantly, continuity for the project.

If you think there’s a conflict between “agile development” and “software architecture”, you don’t understand at least one of them

— Stefan Tilkov (@stilkov) October 3, 2013

Keeping Agile Development from becoming Fragile

Just because you can go fast, doesn't mean you should. (1995 Darwin awards)

In my opinion the technical debt metaphor is over used. In this talk, Howard used conscious technical debt to illustrate the point. That's a trade-off I'm willing to make sometimes, and he gave some good examples of how you could recognize problems early on and counteract them.

Final Thoughts

It's been a bit of a mixed-bag so far. The format of the conference doesn't encourage the conversations that happened at Agile Cambridge. Looking forward to the rest of it though, some exciting sessions on Thursday.