tag:blogger.com,1999:blog-77453381793764401752024-03-05T16:51:28.697+00:00Software Development is About People - Andy Butcher's blogAnonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-7745338179376440175.post-77661820659271445842017-01-06T08:41:00.000+00:002017-01-06T12:32:10.321+00:00The Agile Architect<div>
It seems to me that we all have an understanding of what <a href="https://en.m.wikipedia.org/wiki/Agile_software_development" rel="nofollow" target="_blank">Agile development</a> and <a href="https://en.m.wikipedia.org/wiki/Continuous_delivery" rel="nofollow" target="_blank">Continuous Delivery</a> are, but we're generally less clear on how the role of Architecture fits into this picture. Most of the Agile frameworks fail to mention architects at all, and hence many companies consider architecture to be something that's done "before you get to the Agile bit".</div>
<div>
<br /></div>
<div>
Recently "Evolutionary Architecture" and "Continuous Architecture" have been talked about a lot - techniques which require buy in and alignment throughout the organization. Here's what I've learned about what agile architecture can be done at the coal face in companies where these ideas aren't fully embedded.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<h2>
1. Individuals</h2>
</div>
<div>
<br /></div>
<div>
We still have this idea in the commercial world that the software development process is something like a factory conveyor belt, and <a href="https://en.m.wikipedia.org/wiki/Kanban_(development)" rel="nofollow" target="_blank">Kanban</a> (excellent though it is) sadly reinforces this idea.</div>
<div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnxmFbLD4_jx3WgPgz-5f3VwD2CenGUbMjcT6DXmkDJQKJagPv8oVpFbbrLS6JBpcpoRvuDEv-PFYIcMpyoIfaPFwqSVAEOFG7174X2n7O9lJGSMlvsdfjTI-OzExL1FlFbt-LPS67ls/s1600/conveyor_belt_agile.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="Development as a conveyor belt" border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnxmFbLD4_jx3WgPgz-5f3VwD2CenGUbMjcT6DXmkDJQKJagPv8oVpFbbrLS6JBpcpoRvuDEv-PFYIcMpyoIfaPFwqSVAEOFG7174X2n7O9lJGSMlvsdfjTI-OzExL1FlFbt-LPS67ls/s320/conveyor_belt_agile.png" title="Software delivery shouldn't be a conveyor belt. It encourages high WIP, and low collaboration." width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Software delivery shouldn't be a conveyor belt.<br />
It encourages high WIP, and low collaboration.</td></tr>
</tbody></table>
Two decades of Agile still haven't broken the notion that first this person does this, then that other person does that. Those people have specific roles, with job descriptions.</div>
<div>
<br /></div>
<div>
But in the real world, teams are made up of <i>people</i>, not roles. People aren't designed and built to adhere to precise job descriptions - they're complex, nuanced organisms with a range of abilities, needs, experiences, and motivations.</div>
<div>
For example, the skills and characteristics required to be a BA and those needed to be an engineer are not mutually exclusive. Similarly with architects or testers. People typically have a <i>variety</i> of experience and knowledge - why should we restrain them?</div>
<div>
<br /></div>
<div>
My point is that we shouldn't be prescriptive about what a team looks like. And in the particular case of architectural design, I'd argue that <b>it's not something that only an architect can do</b>. In fact, the designs that architects produce often come (and <i>should</i> come) from the subject matter experts - engineers, testers and so on - who know the details of how it all hangs together, and will be able to identify many of the complexities and edge cases from the outset. </div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<h2>
2. Working Software</h2>
</div>
<div>
<br /></div>
<div>
The traditional idea of Big Design Up Front, and an Architecture Team in their ivory tower is much derided, and rightly so. However it's still a reality in many companies over a certain size.<br />
<br /></div>
<div>
As any software developer will tell you, you can't design code up front and expect it to look like that when you're done. You discover things as you go along; the exact design emerges as you proceed, finding your way along, sometimes going back and refactoring when you perceive a better way of doing something. I still shudder when I remember an architect I once worked with whose idea of architecture was to produce UML class diagrams with literally dozens of classes and interfaces, to throw over the wall to the development team.<br />
<br /></div>
<div>
Most people would agree that architects should work at a high level. However, if they're not involved in the actual implementation of the things they design, they'll never learn about the implications of their decisions at the coal face of development and operations, and will <b>make the same kinds of mistakes over and over again</b>, with other people picking up the pieces.</div>
<div>
So architects should operate at a high level, but strive to understand the low level details - which in practice means being involved with the team right the way through implementation and beyond.</div>
<div>
<br />
If your company thinks that they can be much more efficient having architects working solely on the "initial design phases" of projects then they're mistaken - they should take a long hard look at how smoothly "implementation phases" typically go, and the quality of life of their Ops and Support folk.</div>
<div>
<br /></div>
<div>
Another important aspect here is that if your company is <i>project focused</i> (which is sadly usually the case) rather than <i>product focused</i>, then there may be the temptation to have a High Level Design Phase "before you get to the Agile bit". There's probably a lot of variation in what people understand by the term "High Level Design", so let me just say:</div>
<div>
<br /></div>
<div>
- You <i>do</i> need to understand the bigger picture, so by all means produce an HLD. But...</div>
<div>
- No design work should take more than a day or two. If it does, you're trying to bite off too much scope, or too much detail. </div>
<div>
- I prefer the terms "High Level Approach" for the bigger picture stuff, and "Design" or "Elaboration" for the specific design work needed for a ticket. </div>
<div>
- <b>Aim to do all design work <i>just in time</i></b>. This is in order to avoid waste, and gain and maintain momentum.</div>
<div>
<br />
<br /></div>
<div>
<h2>
3. Collaboration</h2>
</div>
<div>
<br /></div>
<div>
The role of an architect is, in my view, the technical role that can least afford to operate in an insular way.</div>
<div>
There are broadly three types of collaboration which are pretty essential to be effective as an architect:</div>
<div>
<br />
<ol>
<li>Identify and build relationships with all the stakeholders for a particular change (Marketing, Ops, Product, Technical Support, Service Desk...) to make sure that as many aspects as possible have been considered, everyone's aligned, and there are no nasty surprises for anyone later on (including you, if an unexpected requirement or constraint pops up at the eleventh hour).</li>
<li>Brainstorm, refine, and choose a technical approach in collaboration with the team that will actually implement it.</li>
<li><b>Get your decisions and design ratified</b> with all the stakeholders. This is the scary bit. As an architect, your work will be scrutinised and critiqued more widely than anyone else's (except perhaps UX and front end designers, poor bastards). If it's not, then I'd say you're not doing your job properly.</li>
</ol>
</div>
<div>
<br /></div>
<div>
That last point is probably the most important. By communicating and justifying your designs, you're forced to discover exactly how well you understand them, and how well considered they really are. Basically: <b>Talk to people</b>.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<h2>
4. Responding to Change</h2>
</div>
<div>
<br /></div>
<div>
This is always contentious, because no one likes change. Especially when you've slaved away on something, only to find that you have to take 2 steps backwards and redo it now that someone's changed the requirements, or the priorities.<br />
<br /></div>
<div>
However, as we all know from bitter experience, change is absolutely inevitable. And the answer given to us by all Agile frameworks is: Keep it simple, and keep it small. That's because simple, small things are easier to change than complex or big things.<br />
<br /></div>
<div>
This poses an interesting challenge for an architect, whose responsibility is usually to produce some kind of design not piece by piece, but for the design as a whole. And that's why I'd suggest that architectural designs should have two important features:</div>
<div>
<br />
<ol>
<li>Be simple</li>
<li>Be modular</li>
</ol>
</div>
<div>
So we're talking clear separation of concerns. Loose coupling. Avoiding over engineering - remembering what <a href="https://en.m.wikipedia.org/wiki/Extreme_programming" rel="nofollow" target="_blank">XP</a> (my favourite of the Agile frameworks) taught us about <a href="https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it" target="_blank">YAGNI</a>. </div>
<div>
<b>
Designs should be embarrassingly simple</b>: People should look at them and instantly understand them. People should say: "<i>What the hell do we pay this architect guy for? This is obvious!</i>"<br />
(I have a blog post brewing on how we should define and evaluate the effectiveness of people and teams, but here's a spoiler: It shouldn't be how complex and clever we make things).</div>
<div>
<br />
Blindingly obvious things get overlooked all the time. An architect should be one of the key people making sure that doesn't happen.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<h2 style="font-family: sans-serif;">
5. What <u>not</u> to do</h2>
</div>
<div>
<br /></div>
<div>
So I tried to structure this post around the four main tenets of the Agile Manifesto, but I'll close by just listing some common ways that architecture is often done which are inherently <b>not</b> Agile:</div>
<div>
<br /></div>
<div>
<h4>
<u>
Separate Architecture Team</u></h4>
</div>
<div>
This is born of the misguided notion that design is a finite activity, done at the start of a project. Instead: Embed your architects in the teams where the work will be done. Otherwise:</div>
<div>
<br />
<ul>
<li>They'll be making decisions they don't understand</li>
<li>The team won't understand or embrace the vision</li>
<li>The team's unlikely to have any respect for the architect.</li>
</ul>
</div>
<div>
<br /></div>
<div>
<h4>
<u>
Formal architectural governance</u></h4>
</div>
<div>
I'm not saying you shouldn't do this - nobody wants to use an Internet Banking application where no one confirmed compliance with <a href="http://www.iso.org/iso/catalogue_detail?csnumber=54534" rel="nofollow" target="_blank">ISO:IEC 27001:2013</a>.<br />
<br />
But if technical decisions have to go through an Architecture Steering Board, made up of senior techies who, <i>at a distance</i>, make decisions about projects, grant dispensations to "divergence from the original designs", or document "corrective actions" to go on a "programme register" etc. etc., then people simply won't bother. <b>People will work around it</b>.<br />
<br /></div>
<div>
<b>
Better to trust the people we employed to actually know what they're doing</b>. </div>
<div>
(Test things - of course. Everyone makes mistakes. But don't centralise control - in my experience that kills efficiency and motivation).</div>
<div>
<br /></div>
<div>
<h4>
<u>
Accurate Architecture Models</u></h4>
</div>
<div>
By this I mean the kind of architecture topologies you create in tools like Enterprise Architect and others, where the boxes and lines aren't just boxes and lines - they have properties, and the modelling software understands the boxes as <i>entities</i> with behaviours and relationships with other entities.<br />
<br /></div>
<div>
While I applaud the aspiration to have an architecture repository, <a href="https://www.opengroup.org/togaf/" rel="nofollow" target="_blank">TOGAF</a> style, experience has shown this to be a futile exercise.</div>
<div>
Don't do it, for goodness' sake, especially if it's manually updated. You'll spend your life trying to keep it updated for very little value.</div>
<div>
<b><br /></b>
<b>The main value of architecture diagrams is to communicate a concept</b>. These tools, which strive for <i>accuracy</i>, impose limits on the kind of information you can convey, Typically you'll struggle to bring out the important features without showing the unimportant ones too. And with a restricted palette of visual indicators, you won't be able to bring out all the things that matter (high risk areas, data flow versus flow of control, areas that are changing in different phases, variations by environment, areas holding or transporting sensitive data, and so on).<br />
<br />
And of course you'll probably diagram the same thing more than once for different stakeholders at different levels of abstraction - and no one likes looking at diagrams which are uniform and soulless. As humans we like things to be visually compelling, and tools like EA really, seriously, aren't.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<h2>
In summary</h2>
</div>
<div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzCe9c8HRmtcolzd9LlKzMJGR7ODKszix4hql5zi4VDO-d5k9EsDEXqiRbZoFwGUsyUHzBlOBauJjTrEOAVgHrey3Il6J66bVXNfKygFWXxV9UTxgp6UZVZXm9XzKsVFGYi19AInOgC9M/s1600/embedded_architect.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="Picture of an architect working *with* the implementation team" border="0" height="237" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzCe9c8HRmtcolzd9LlKzMJGR7ODKszix4hql5zi4VDO-d5k9EsDEXqiRbZoFwGUsyUHzBlOBauJjTrEOAVgHrey3Il6J66bVXNfKygFWXxV9UTxgp6UZVZXm9XzKsVFGYi19AInOgC9M/s320/embedded_architect.png" title="Avoid hand offs. Get the people you need working together on each small thing, all the way through. That includes architects!" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Avoid hand offs. Get the people you need <br />
working together on each small thing, all the <br />
way through. That includes architects!</td></tr>
</tbody></table>
<br /></div>
<div>
The responsibility of an architect is to be the person who has thought of things from all angles, and from the broadest possible perspective; they should take the high level strategic view.<br />
<br />
But that doesn't mean that they shouldn't involve themselves in the detail of the implementation. Architecture should come from the people who <i>know</i> the detail, and be ratified by them (as well as all other stakeholders). It's the architect who makes all this happen - collating, rationalising, and aligning - <b>driving technical decision making</b>. Ensuring that the design is <b>as simple as possible</b>, and <b>as modular as possible</b>.<br />
<br />
Finally, the architect should be <b>a member of the implementation team</b>, collaborating on design <b>just in time</b>, rolling their sleeves up when necessary, and paying attention to the <b>build, deployment, and operational support</b> of the stuff they build.<br />
<br /></div>
<div>
It's common sense really - which, at the end of the day, is what Agile is really all about.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<h2 style="font-family: sans-serif;">
Further reading</h2>
</div>
<div>
<a href="http://www.agilearchitect.org/">http://www.agilearchitect.org/</a> - a pragmatic and detailed guide to agile architecture</div>
<div>
<a href="https://pgppgp.wordpress.com/2014/08/18/continuous-architecture-principles/">https://pgppgp.wordpress.com/2014/08/18/continuous-architecture-principles/</a> - the 6 principles of continuous architecture from the blog by Pierre Pureur (co-author of <a href="http://shop.oreilly.com/product/9780128032848.do" rel="nofollow" target="_blank">Continuous Architecture</a>).</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com21tag:blogger.com,1999:blog-7745338179376440175.post-33740376729651964672016-05-17T08:14:00.000+01:002016-05-23T07:26:11.515+01:00The Shit Nightclub antipattern<div dir="ltr">
You go to a fancy looking nightclub. It's on Leicester Square in London - it must be good. The thumping music carries with it on the evening air the magical lure and promise of good times, so you pay the £20 entry fee and the suited bouncers let you in.</div>
<div dir="ltr">
Then you discover that there's no one in there. And as the minutes and hours slip by, the place doesn't really fill up - but it's sure to soon, right? One of you suggests going somewhere else, but you point out that you've all paid £20 to get in. We should stick it out a bit longer.</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
And this is what happens with large IT projects.</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
Now IT projects are hard. No two are the same due to the shifting quicksand of technology, and the particular perspectives of the myriad stakeholders involved.</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
IT projects are also time consuming. They usually take at least twice as long as anyone thought they would - mainly because of the first point; <i>no one can hold all of it in their heads</i>, or at least not in "working memory".</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
Lots of problems stem from these two things: Budgets get blown out of the water, businesses don't get to market quickly enough, a work-late culture develops, morale ebbs away...</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
But like any teacher will tell you, just because it looked great on your lesson plan, if it's not working <b>abandon it</b>!</div>
<div dir="ltr">
And this is what businesses are often unable to do. </div>
<div dir="ltr">
<br></div>
<div dir="ltr">
This is what happens:</div>
<div dir="ltr">
<br></div>
<ul>
<li>Someone estimates the project as 3 months.</li>
<li>A team breaks down the work and adds up the estimates. It becomes 6 months. (If you break work down and add it up, the estimate will <b>always</b> grow).</li>
<li>Some things get de-scoped. Some estimates get squeezed. They arrive back at the 3 month estimate, and senior stakeholders are appeased.</li>
<li>Work begins, and in the early days it becomes clear that things are slipping. Badly. But the PM (yes we're probably talking about a non-Agile environment) sits on this information rather than put the cat among the pigeons - after all it's early days, we might be fine.</li>
<li>The three month deadline approaches, and the PM goes cap in hand to the stakeholders and makes a poorly thought through request for one more month.</li>
<li>Two months later the team is exhausted and miserable, and the backlog is still groaning with work (including the performance testing - everyone agrees we really should get going on that). </li>
<li>The PM is secretly angry with the team - how can they have taken so long? Why is it always like this?</li>
<li>The stakeholders are angry with the team - they put money and reputation on this project, and these developers are obviously not up to the job. More developers are dragged (possibly literally) to join the team.</li>
<li>The developers are all talking about leaving (except the guy who isn't very good).</li>
<li>The system is now complex and buggy, and more worryingly, it's laughably far from the performance targets they set at the start. How can it take 20 seconds to return a page?</li>
<li>At 6 months, a senior architect or tech lead is parachuted in. The PM is changed. More and more money is sunk into the project. <b>It can't fail now, otherwise everyone's wasted half a year and a scary amount of money. More importantly, the stakeholders will look like fools.</b></li>
<li>The project limps out the door at 9 months, performing poorly and riddled with bugs.</li>
<li>The business decides they need more rigid and formal processes to stop this happening again.</li>
</ul>
<div>
<br></div>
<br>
<div dir="ltr">
So if you find yourself in a shit nightclub, consider your options:</div>
<div dir="ltr">
1. Stay. Then you'll end up having spent lots of money, and having had a shit night.</div>
<div dir="ltr">
2. Leave. Then you'll end up having spent lots of money, and possibly having a good night.</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
Your choice.</div>
<div dir="ltr">
<br></div>
<div dir="ltr">
<br></div>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com6tag:blogger.com,1999:blog-7745338179376440175.post-61265979935562780092015-10-15T08:54:00.004+01:002015-10-15T08:54:47.625+01:00Nuance and momentum<div dir="ltr">
In most companies there's an understandable reluctance to commit significant budget to new ideas unless they're very well proven, and - critically - enough people in senior positions think they're good ideas.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
So in order to get sufficient momentum for an idea, it needs to be repeated and communicated many times - and thereby loses any <i>nuance of meaning</i>. It becomes necessary to distill the essence of it into an "executive summary" that, especially for technical ventures, often misses the point by a small but important margin.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
In the company I currently work in, various technical people, including myself, have been pitching to refactor a particularly complex area of our architecture. It doesn't perform as well as it needs to, and is also the frequent source of insidious bugs in our live environment which are hard to debug since the system is hard to reason about. </div>
<div dir="ltr">
We have a proposal for how it could be designed differently, but in order for this proposal to <i>gain momentum</i>, the point of the work has been diluted through Chinese whispers to the basic premise of "Make it go faster". The enormous benefits in <span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);">future technical enablement are glossed over. (Of course, in most companies, eliminating technical debt is considered a Good Thing, but when it come to the crunch, no one wants to invest in it. Where I work now is a hundred times better than most at this, but it's still short term wins that really get people going).</span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);"><br /></span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);">Why does this matter? T<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);">he message that has become fixed on is the <i>short term performance benefit</i> which yields greater opportunity for sales. This benefit is much smaller than the more intangible longer term advantages, and so the idea hasn't made it very high on the agenda.</span></span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);"><span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);">What's more, ideas with <i>no</i> short term benefit will probably gain no momentum at all.</span></span></div>
<div dir="ltr">
And when (if?) the idea comes to be engineered, the senior business stakeholders may be impatient for it to be completed, as they don't understand the nuances of how much long term benefit they will be getting. In some companies, this can lead to the project being canned before it's complete (see <a href="http://mrandybutcher.blogspot.co.uk/2015/10/death-by-thousand-incomplete.html">Death By a Thousand Incomplete Refactorings</a>), or made more difficult by technical teams being asked to work on short term things in parallel.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);">If only business people could invest more time in understanding technical matters. Of course, one barrier is that us techies are often resistant to that at a subconscious level - we take pleasure in our area of expertise being impenetrable in much the same way I suspected Polish people liked seeing me struggle with their pronunciation and grammar when I lived there. (Different endings for different numbers of things - seriously?)</span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);"><br /></span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);">But the other barrier is that we make our systems too complex. Perhaps a good rule of thumb should be: If non-technical people don't understand our systems, then they're too complex.</span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);"><br /></span></div>
<div dir="ltr">
<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);">So, returning to the topic of gaining momentum and losing nuance, what's the answer? It seems to me it's the same answer I return to again and again in IT (and many other areas): </span></div>
<div dir="ltr">
<b>Better to restructure your organisation to allow for small independent teams to make their own decisions and set their own direction</b>. That way, less momentum needs to be built up and more nuanced communication can occur, using a rich shared vocabulary.</div>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com1tag:blogger.com,1999:blog-7745338179376440175.post-49059879355271291012015-10-15T08:51:00.001+01:002015-10-20T09:54:17.760+01:00Is Eliminating Cross Team Handoffs Possible?No.<br />
<div>
<br /></div>
<div>
Well, not completely anyway. <b>But just because you can't achieve something doesn't mean you shouldn't strive for it.</b></div>
<div>
<br /></div>
<div>
Lots of advice floating around in the Agile space tells you that handoffs from one team to another are expensive and inefficient: The DevOps movement has given way to the Anti-DevOps movement, suggesting that the development team should do their own Ops; I've written about <a href="http://mrandybutcher.blogspot.co.uk/2015/10/the-vicious-cycle-of-support.html">The Vicious Cycle of Support</a> whereby the development team should support their own output; separating business teams from technical teams can lead to an unpleasant client-supplier relationship where neither side can work effectively.</div>
<div>
So do we just need one huge team with everyone in it?</div>
<div>
<br /></div>
<div>
Well, yes. Except for the "huge" bit.</div>
<div>
<br /></div>
<div>
It's been a core concept of most Agile doctrines that you keep your team small, and your immediate scope small. And the people in that team don't just stick to one role - they chip in and help out wherever it's needed.</div>
<div>
I've said before that I think <b>the optimum set up is two developers and a product person</b>. That assumes, however, that all those people are very experienced, and are willing to cover off between them the jobs that we typically divide up into the separate roles of Business, UX, Design, Coding, Testing, Release, Support and so on. That may sound ambitious, but consider the benefits:</div>
<div>
<br />
<br />
<ul>
<li>No communication overhead. Everyone knows <i>exactly</i> what's going on, and everyone is working from the same assumptions.</li>
<li>Focus. There's no way you're going to be able to juggle 5 projects at the same time like bigger teams are often expected to do.</li>
<li>A sense that you really are a team, and that you <i>own</i> this deliverable end to end. <span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);">This is the same reason that startups are such exciting and dynamic places to work, and often take the market by storm. </span></li>
<li>You wake up and feel motivated to come to work! It's fun. And when people have fun doing their jobs, all sorts of virtuous cycles develop. Talented people want to come and work for you. People feel inspired to come up with genuinely new and exciting ideas.</li>
<li>Everyone in that small group is forced to understand all the domains end to end, which were previously kept separate. And when people understand things end to end, your quality shoots up because there are no unexpected implications from decisions made in isolation; there are no lost opportunities ("if I'd known that was something we'd want to do, I'd have built it differently!")</li>
<li>The team can be autonomous. No more waiting. No more chopping and changing at the whim of far-removed senior management or marketing teams. With clear goals, and empowerment, it's pretty amazing what three people can achieve.</li>
</ul>
<div>
<br /></div>
<div>
(In case you're wondering why handoffs are bad, see <a href="http://brodzinski.com/2011/12/handoffs-are-bad.html">Pawel Brodzinski's blog post</a> on it)</div>
</div>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com1tag:blogger.com,1999:blog-7745338179376440175.post-70217161553865124022015-10-15T08:44:00.000+01:002015-10-20T09:57:21.997+01:00The Vicious Cycle of SupportDevelopers who don't have to support their code in Production unsurprisingly don't consider all the implications of their changes.<br />
<div>
Logging, monitoring and alerting are afterthoughts. Questions like "What happens when the network fails?", or "What if we run out of disk space?" aren't at the forefront of people's minds.</div>
<div>
The difficult test scenarios get ignored because "We should probably test those things, but the test environments are rubbish and besides, this is how we've always done it."</div>
<div>
<br /></div>
<div>
But the result isn't just that a particular feature going live drags some poor guy out of bed at 3am (the traditional time that hypothetical production issues take place). And it isn't just that the metrics on number of live incidents rises over time. It goes much deeper than that.</div>
<div>
<br /></div>
<div>
When Support teams are separate to Development teams, developers don't understand the domain of Support, and vice versa.</div>
<div>
<br /></div>
<div>
The problem with the former is that systems that weren't designed to be supported are hard to support. <b>The cost of that support effort grows over time.</b></div>
<div>
<br /></div>
<div>
The problem with the latter is that if Support people make fixes, they do so <b>without understanding the domain fully.</b> This causes further instability and technical debt, and also creates a system which <b>neither developers nor support people understand.</b></div>
<div>
Of course, developers continue to build on these foundations, which compounds the problem still further.</div>
<div>
<br /></div>
<div>
Still, you shouldn't be downhearted as a developer in this kind of company. At least you don't have to support it!</div>
<div>
<br /></div>
<div>
See <a href="http://mrandybutcher.blogspot.co.uk/2015/10/is-eliminating-cross-team-communication.html">Is Eliminating Cross Team Handoffs Possible?</a></div>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com2tag:blogger.com,1999:blog-7745338179376440175.post-39379018444423015582015-10-15T08:36:00.000+01:002016-05-17T08:27:37.585+01:00Death By a Thousand Incomplete Refactorings<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Start with a fairly new IT system. The lead developers built it with a Shining Vision of the perfect architecture, and that vision has been realised. The team has put most of the finishing touches on it, the initial waves of bugs have been exterminated. We're proud of it. We even spend some time refactoring a couple of bits we rushed.</span><br />
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">The lead developers feel like heroes. They stick around for a couple of years basking in the glory of being the people who understand the system inside and out.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">And then, gradually, the realisation dawns that there's some technical debt which needs addressing. Possibly it's been there all along, it's just that the system scaled or was extended in ways we didn't anticipate. Possibly it's caused by developers building stuff without understanding the Shining Vision. Possibly it's down to <a href="http://mrandybutcher.blogspot.co.uk/2015/10/the-vicious-cycle-of-support.html" target="_blank">The Vicious Cycle of Support</a>.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfOnMSEdXOGbBZZroFCMVvSMikGGQQpXTN_-V_2CVlGrGCCVo8t4lQTz6gDMYdqA_xL19saxemK8SsXsmZ5EQcznm6psCjOpGtwrX3ueQVe1umGQ4lJSwI048rzsdYiQsAd50g_XNC0xE/s1600/Refactoring+1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="156" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfOnMSEdXOGbBZZroFCMVvSMikGGQQpXTN_-V_2CVlGrGCCVo8t4lQTz6gDMYdqA_xL19saxemK8SsXsmZ5EQcznm6psCjOpGtwrX3ueQVe1umGQ4lJSwI048rzsdYiQsAd50g_XNC0xE/s320/Refactoring+1.png" width="320" /></a></div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Whatever it is, the Make it Shiny Again project is born. One of the original veteran lead developers spends all day every day telling people about how the Shining Vision got lost, and now enough senior people have listened. Troops are mobilised.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">The big refactoring goes well at first. Everyone is behind it. Update emails go out gleefully reporting the excellent progress. Demos happen. Meetings show high level progress and sing the praises of the Make it Shiny Again project. It will destroy disease in the third world. It will bring peace to the Middle East. It'll even increase our unit test coverage.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwTG8EDvaCWgJn_4meBSLtNYfnUgnlmea9lTRA1DBWh2HQdVb9xqmPwYCECbOAMIrO2ci1U5pMDYk0MGeX6HCFvD4jPxGp6dum741yp1vpUnApMHPB-yUsasoc06O0q8wggY-aM5OgghY/s1600/Refactoring+2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="134" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwTG8EDvaCWgJn_4meBSLtNYfnUgnlmea9lTRA1DBWh2HQdVb9xqmPwYCECbOAMIrO2ci1U5pMDYk0MGeX6HCFvD4jPxGp6dum741yp1vpUnApMHPB-yUsasoc06O0q8wggY-aM5OgghY/s320/Refactoring+2.png" width="320" /></a></div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">But, inevitably, as the project stretches on and the full scale of the task becomes apparent, people begin to lose energy. It looks like the timescales are moving out. Fewer and fewer people are extolling the virtues of it. Even the veteran lead developer has got distracted by a new even shinier way of doing things. The project joins the ranks of other tedious long term projects with no sense of urgency, gathering dust at the bottom of the project plans. (In some companies, "long term project" means years. In some it means weeks. Either way, energy attrition occurs).</span><br />
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh75MavK861VDXfqvHiXf7DxFC1x-wqnBaq1SQ4Ms6AVtMzJIgbgRzXeCAnU9FugEsEkW90hCM2mavVXLB8wxN46Q27hKanq_VPYyq5qeR59QWwXcIl_y-W8buMAR1h47hxzSDrVgc_45Q/s1600/Refactoring+3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="178" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh75MavK861VDXfqvHiXf7DxFC1x-wqnBaq1SQ4Ms6AVtMzJIgbgRzXeCAnU9FugEsEkW90hCM2mavVXLB8wxN46Q27hKanq_VPYyq5qeR59QWwXcIl_y-W8buMAR1h47hxzSDrVgc_45Q/s320/Refactoring+3.png" width="320" /></a></div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Eventually something goes live. It may feel like a pyrrhic victory, but it delivers value. One part of the system has been refactored, and is running successfully alongside the old system. No one has the energy to celebrate.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Some conscientious members of the team ask when we'll move on to the next phase of refactoring. Tumble weeds drift across the office floor. Strangely, no one fancies descending back into that dark chapter of their lives.</span><br />
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">The final solution, once all functionality had been refactored, meant the switching off of the old system:</span><br />
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpFmD-BmjA071hIyaGYiBlvUOLX-mHOFVKB1sTWOFVfNTMvwrvm-EgF1fwky9dcGnaLJlAB_zG6v6vc1H1r7eWn5Vm5z6ZUvrqeg6Tk2OiBhjirmbi76sp_MzHMUU6uR8gn-qebZdeHgI/s1600/Refactoring+4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="139" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpFmD-BmjA071hIyaGYiBlvUOLX-mHOFVKB1sTWOFVfNTMvwrvm-EgF1fwky9dcGnaLJlAB_zG6v6vc1H1r7eWn5Vm5z6ZUvrqeg6Tk2OiBhjirmbi76sp_MzHMUU6uR8gn-qebZdeHgI/s320/Refactoring+4.png" width="320" /></a></div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">However, what the Make It Shiny Again project actually achieved was this:</span><br />
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0juMvPcWvnkKrT0pfKlZprJGfl6iXDwjfC2W9OwV9vUmeusbkvR7s2QJ_qKWt8ICtkrrNgsTpNQ7EvWh5QWEsaNmk2aBAk4oLqEkKspwoWf0244Tx6lgjC1isVA6SgMaVC2X1EyUJyPM/s1600/Refactoring+final.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0juMvPcWvnkKrT0pfKlZprJGfl6iXDwjfC2W9OwV9vUmeusbkvR7s2QJ_qKWt8ICtkrrNgsTpNQ7EvWh5QWEsaNmk2aBAk4oLqEkKspwoWf0244Tx6lgjC1isVA6SgMaVC2X1EyUJyPM/s320/Refactoring+final.png" width="320" /></a></div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Now drill deeper and look at the code. Many many incomplete refactorings of different things have happened. Everyone touching the code has either not understood that particular area's Shining Vision, or has sought to impose their own.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Now look at it from 30,000 feet. Whole swathes of the architecture (and the organisation) have undergone incomplete refactorings.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">If you squint a bit, the architecture is a fractal. It looks like spaghetti at any level.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">No wonder it all feels like such a mess. The solution? </span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Let me unveil my Shining Vision. We'll finish it this time, honestly we will.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<b><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">Less bleak footnote</span></b></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">This <i>can</i> be avoided. Some technical debt is inevitable<a href="https://www.blogger.com/blogger.g?blogID=7745338179376440175#1" name="top1"><sup>1</sup></a>, but Death By a Thousand Incomplete Refactorings is not:</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">- Don't bite off more than you can chew.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">- Deliver in <i>small increments. </i>If it's going to fail, make sure it fails early.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">- Celebrate each small success. </span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">- Swap people in and out - keep it fresh. Let everyone be involved.</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;">- Recognise the risk of an incomplete refactoring!</span></div>
<div>
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<br /></div>
<hr width="80%" />
<span class="Apple-style-span" style="font-size: x-small;"><br />
<a href="https://www.blogger.com/null" name="1"><b>1 </b></a>See Martin Fowler's <a href="http://martinfowler.com/bliki/TechnicalDebtQuadrant.html">TechnicalDebtQuadrant</a><a href="https://www.blogger.com/blogger.g?blogID=7745338179376440175#top1"><sup>↩</sup></a><br />
</span>Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com2tag:blogger.com,1999:blog-7745338179376440175.post-12889888953976118722014-05-08T07:33:00.001+01:002014-05-20T07:44:28.685+01:00Bend Over Backwards. Now Stay There.<p dir="ltr">High staff turnover is a bad thing. Pretty much everyone would agree on that - especially for a development team where knowledge of the system is essential.<br>
In fact surely keeping staff happy - retaining the best talent - is a priority for all managers.</p>
<p dir="ltr">But when the pressure's on, IT managers will end up cascading the misery to their team for the simple reason that all managers are primarily judged on and therefore incentivised by <b>meeting project deadlines</b>.</p>
<p dir="ltr">Meeting deadlines means meeting budgets and delivering ROI. In other words, it means <b>making money </b>- and this is the only priority of any company anywhere regardless of what their website says about CSR, diversity or people development. Money is all they care about - make no mistake.</p>
<p dir="ltr">So what does this mean for you as a developer? It means that the only person you can rely on to look out for you is yourself. If you regularly bend over backwards to meet deadlines then that becomes the norm. If you join the Working Late Gang, you give them strength in numbers - it becomes the culture. The unrealistic expectations, the flawed process, the poor planning - all of it is hidden or condoned by you picking up the strain and making it happen.</p>
<p dir="ltr">Stop.</p>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com1tag:blogger.com,1999:blog-7745338179376440175.post-5194060236114400572014-02-27T07:19:00.001+00:002016-05-17T08:32:14.453+01:00Lazy developers?Everyone wants to get an IT project finished on time. Why would they want anything else? There's no fun in being part of a "zombie project" that never dies - developers want to move on to new challenges, new cool things.<br />
<div>
And yet there's often an unspoken assumption that the reason things weren't done on time is that developers are basically lazy.<br />
<div>
<br /></div>
<div>
Here's one of the main reasons why I think that.</div>
<div>
<br /></div>
<div>
Developers come up with an estimate for a piece of work which they believe is realistic. Depending on their experience and personality they might be overly optimistic or pessimistic. But at the end of the day they are the technical expert whose specific responsibility it is to estimate, design and build software. (Of course, it should <b>always</b> be the person who's responsible for building a thing that should provide the estimate for it).<br />
<br /></div>
<div>
And still, if the manager or business stakeholder who hears the estimate believes it's too high, they will usually squeeze it, despite the fact that they're <b>neither responsible nor qualified</b> to specify estimates. This squeezing can be overt, or surreptitious. Often it will take the form of putting pressure on the developer (<i>"But are you really sure that piece will take 10 days? It's just config isn't it?"</i>), or, even worse, it will be done without the developer even being consulted, by a coven of project managers, pressured into finding "creative solutions" to meeting the dates the business had in mind, convincing themselves that things can be parallelised, done more efficiently, or done by "just copying" something done previously. </div>
<div>
<i>"Pete said a maximum of 4 people could work on this, but there's bound to be stuff we could get one of the Indian guys to work on. And this user story says 10 days - but it's pretty much what we did last time. If we said it was only 6 days we pretty much meet the deadline, as long as no issues come out of test."</i></div>
<div>
<br />
The problem, in a nutshell, is that people don't believe that the developers have thought "creatively" enough about how to meet the deadline; on some level they're trying to give themselves an easy ride.</div>
<div>
It doesn't seem to occur to them that they could simply go back to whoever demanded an earlier deadline and say <i>"No I'm afraid we can't do that. I've worked it through with Pete, and we don't think it's achievable."</i></div>
<div>
<br /></div>
<div>
I got a bit of a thrill saying that. Let me try some more things that rarely get said by project managers:<br />
<br /></div>
<div>
<br />
<ul>
<li><i>"I'd need to consult with Pete, it's not my remit to say whether or not we can add more people to that."</i></li>
<li><i>"It'd be best if we didn't distract Pete right now to ask him for estimates on this. He's maxed out."</i></li>
<li><i>"The team as a whole has had 5 distractions this sprint already, and that's our stipulated maximum, sorry."</i></li>
<li><i>"No, Pete said 10 days. He might turn out to be wrong because it's just an estimate, but he's the most qualified person to provide that estimate and we have to go with that."</i></li>
<li><i>"No we can't commit to that date. We don't know if it's achievable or not. But we can commit to delivering the stuff you said was highest value first, and involving you all the way."</i></li>
<li><i>"We could try and achieve that, but the team's been flat out on this stuff for months, and are having a pretty tough time. We need to try and find a sustainable pace for everyone's sanity."</i></li>
</ul>
</div>
</div>
<div>
<br /></div>
<div>
But those things pretty much never get said, especially the last one.</div>
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com0tag:blogger.com,1999:blog-7745338179376440175.post-53604419654782825802012-11-21T08:44:00.002+00:002012-11-21T08:44:54.352+00:00Designers onshore, coders offshore?Like many companies, we operate the "offshore model" whereby the bulk of our development team is comprised of developers contracted to us from abroad where relative currency strength works in our favour. India is the most common choice. This model makes a lot of sense for two reasons:<br />
<br />
1. As work waxes and wanes, or if times get hard and the team needs to be downsized, the number of people offshore can be increased or reduced easily, and without recruiting or losing permanent members of staff.<br />
<br />
2. It's cheap. <br />
<br />
However, for me, this model poses two fundamental problems as well; one directly, and one indirectly. <br />
<br />
1. Working with developers who aren't in the same office as you is hard. Working with people who aren't in the same time zone as you is even harder. And collaborating with people whose first language isn't English (often on a poor phone line) makes it harder still. <br />
I believe that the impact on productivity <span class="Apple-style-span" style="font-size: x-small;">[1]</span> caused by these things risks outweighing the financial benefit.<br />
<br />
2. Usually there's not much of a recruitment process involved; rarely even a coding test or technical interview. Managers ask the offshore company for another 5 "resources", and on Monday morning there they are on the end of the crackly phone line. However, the offshore team you accrue often have less than a year or two's development experience. <br />
Now don't misunderstand me, I have no issue with junior developers (I was one after all), but I believe that junior developers need support and development - precisely the sort that is usually denied to offshore contractors: training, educational sessions, mentoring and so on. They are often denied access to the business and therefore an understanding of the problem domain and context they're working within.<br />
Considering all of the above, it should come as no surprise that the quality of their output isn't always up to scratch. <br />
<br />
However it <i>does</i> come as a surprise to managers when code quality decreases, and team efficiency and morale slowly decays. They never say: "perhaps it's the fact that a large number of the team [perhaps even the majority] are geographically disconnected and not very experienced".<br />
<br />
Why not?<br />
<br />
The answer lies in one of the great myths of software development: Your team should consist of Designers and Coders.<br />
<br />
This is how the myth goes:<br />
<br />
The Designers are the permanent, onshore, team. They have the knowledge of the business, and are usually more experienced and (hopefully) have time and money invested in their development. They're the "intellectual capital". They may even be flattered into thinking that they should move away from the daily grind of actually cutting code as that's beneath them. After all, they do Design with a capital D.<br />
<br />
The Coders on the other hand are ten a penny, and can be less skilled - after all, all they do is write the code, and implement the design which the Designer came up with. Practically anyone could do that. <br />
<br />
Right? <br />
<br />
Well my opinion is: Wrong. Absolutely wrong. And here's why: Coding is design. <span class="Apple-style-span" style="font-size: x-small;">[2]</span><br />
<br />
Almost every line of code I write involves a design decision: Do I use an instance variable or a local variable? Do I make this component request-scoped or globally-scoped? Do I hold this data in a Map or a List?<br />
All these decisions add up to create code which is more or less extensible, performant, resilient, secure, maintainable and so on - and almost all of these decisions are too detailed to be made by the Designer. (Having said that, every now and then you do meet a Designer - who may also call himself an Architect - who creates designs to this level of detail. In my experience these designs are almost as large as the code itself, unwieldy*, and probably full of oversights and mistakes which only become apparent when you actually cut the code).<br />
<br />
<span class="Apple-style-span" style="font-size: x-small;">(* As Martin Fowler </span><span class="Apple-style-span" style="font-size: xx-small;">[3]</span><span class="Apple-style-span" style="font-size: x-small;"> points out: For diagrams, comprehensiveness is the enemy of comprehensibility.)</span><br />
<br />
So what does this mean?<br />
<br />
It means you should get your experienced developers to write code. They should be both Designer and Coder - with no distinction drawn between the roles. <br />
<br />
Let me give you a scenario I've experienced, and seen, many many times.<br />
Working as the Designer, I produce a documented design and go through it with the Coders. The Coders are fairly junior, so this process takes a while. <br />
A few days later I ask to see the code, or I get a code review request. When I look at it, I see that their interpretation of the design isn't exactly how I imagined it.<br />
For some things I can clearly explain to them why the way they've done it is problematic, and I ask them to change it. <br />
But some things are less easy to justify. I know it's not how I would have done it, but it's getting late in the project to refactor things. It seems to work okay - so I say "you know what, just leave it as it is - it's probably fine."<br />
<br />
When a production issue occurs three weeks later I realise why it should have been done the way I instinctively thought it should be done.<br />
<br />
Sometimes it's not a production issue, but we suddenly need to extend the functionality in a new way which the implementation makes more difficult - but funnily enough if it had been implemented the way I would have done it - had I been the Coder and not just the Designer - it would have been easy to extend in this new way. <br />
<br />
A variation on the above is that the experienced developer (the Designer) is so thinly spread that she actually finds she doesn't have time to review all the code the junior developers (the Coders) have produced. This makes issues with the low level design even more likely - and when the production issue occurs, the Designer looks at the code and exclaims "WTF!?" (which means What Terrible Foolishness!)<br />
<br />
So on the off-chance you're a manager with the authority to control how your development team is managed and resourced, try giving quality a fighting chance. Abandon the offshore model and give your permanent team everything they need to do their jobs well. <br />
You'll be amazed at the difference it makes. <br />
<br />
<br />
<br />
<span class="Apple-style-span" style="font-size: x-small;">References:</span><br />
<span class="Apple-style-span" style="font-size: x-small;"><br /></span>
<span class="Apple-style-span" style="font-size: x-small;">[1] Zenun et al: The Effects of Teams' Co-location on Project Performance http://extras.springer.com/2007/978-1-84628-975-0/col/dpi.inpe.br/ce@80/2007/01.22.18.46/doc/paper.pdf</span><br />
<span class="Apple-style-span" style="font-size: x-small;"><br /></span>
<span class="Apple-style-span" style="font-size: x-small;">[2] The reader who can tell me who first said this wins a Cadbury's Fudge, because I can't find this reference anywhere. It was probably Kent Beck, Ken Auer or Roy Miller.</span><br />
<span class="Apple-style-span" style="font-size: x-small;"><br /></span>
<span class="Apple-style-span" style="font-size: x-small;">[3] Fowler, Martin: Is Design Dead?, http://martinfowler.com/articles/designDead.html</span><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com0tag:blogger.com,1999:blog-7745338179376440175.post-84534921335236733912012-07-24T19:50:00.001+01:002012-08-09T07:38:25.741+01:00The MeetingThe automated voice of the teleconference lady announces: "Now joining... Name not recorded".<br />
The meeting has started late, and the latecomers are still arriving. This is mainly because everyone has so many meetings to attend, they're still trying to make it from the last late-running meeting to this one. The host starts a pre-amble.<br />
"Okay everyone, first of all sorry we've started a bit late! Can I just - "<br />
The automaton interrupts him: "Now joining... Name not recorded".<br />
"...can I just check - "<br />
"Now joining... Name not recorded".<br />
"...who's on the call?"<br />
There is silence.<br />
"Do we have Jack?"<br />
<br />
"Kathy?"<br />
<br />
"What about Brad?"<br />
<br />
While we wait, I look around the room and take in the cast of characters on our end of the phone.<br />
<br />
First there's the Meeting Nomad who, although a project manager by job title, in reality drifts from meeting to meeting and sets up camp behind his laptop where he does other work, without listening to or participating in the meeting he is currently inhabiting. Consequently he learns nothing and adds no value to the proceedings. <br />
<br />
Next is Loudmouth whose role is to assert his superiority in all situations, never allowing his complete lack of understanding to become an obstacle to this. He will have to be managed if there is to be a useful outcome, but sadly the ineffective host has none of the required skills to do this.<br />
<br />
Next round the table, and sat next to me, is the Junior Developer who has the deepest understanding out of all of us of the issues about to be discussed, but whose lowly rank relative to Loudmouth will necessitate his silence.<br />
<br />
To the other side of me are Network Guy 1 and Network Guy 2, invited because most of what we'll be discussing will involve computers, and computers connect to networks. They also will say nothing throughout.<br />
<br />
Finally there is the aforementioned Inept Meeting Host who, having ascertained who is on the call, is now having problems with his laptop and is swearing under his breath as he tries to bring up the document we were going to discuss. This regular occurrence surprises only him.<br />
<br />
That leaves me. My mission, should I choose to accept it, is to attempt to come away with specific actions and decisions which will be of use to the Junior Developer who has 2 weeks to complete the work.<br />
<br />
The Inept Meeting Host has now managed to bring up the document, but has failed to circulate it. He decides to email it round, but unfortunately his laptop claims never to have heard of our WiFi network. There ensues a lengthy period during which time Loudmouth and one of the Network Guys huddle round his laptop and join in with a Random American on the phone in offering suggestions. <br />
(The Random American, incidentally, is only random because I have never heard of him, but from his authoritative tone I assume he is some kind of manager in the vast and bewildering hierarchy of managers there seems to be).<br />
I lean across to the Meeting Nomad.<br />
"Do you know if anyone from Test is coming?" I ask.<br />
He looks up from his laptop and blinks as his eyes adjust to the real world. "Test?" he asks, as if he hasn't heard of this team before. I consider the possibility that perhaps he hasn't.<br />
"You know, Adrian's team. We need someone to test this stuff don't we!"<br />
He frowns slightly. "Do we? No-one mentioned that to me."<br />
I sit back. <br />
<br />
Eventually they manage to connect to the Internet, but for some reason Outlook cannot connect.<br />
<br />
The Inept Host is now, at someone's suggestion, setting up a Webex in order to share his screen and is in the process of requesting a password reset email since he has forgotten his password, and Network Guy 1 had told him to clear his cookies. No-one has remembered that he is unable to access his email so will be unable to receive the new password.<br />
<br />
20 minutes into the hour-long meeting the laptop remembers that it in fact does know the WiFi network, the document is circulated, and we begin.<br />
<br />
There is no agenda, but minutes for this meeting (were anyone taking minutes) could read something like this:<br />
- Tedious walk-through of a document which everyone was supposed to have already read. <br />
- Heated discussion around a minor point which Loudmouth knows a lot about. Action: Junior Developer has to ensure code correlates with an obscure standard, presumably in case we decide that this [2 week ill-conceived, poorly-thought-through hack inspired by short-term thinkers in the business with a dismal record in shrewd decisions] is such a good piece of software we may one day decide to put our logo on it and take it to market as an off-the-shelf product. <br />
- Back Office Guy [who arrived, grinning, 46 minutes in] raised the fact that the proposed global solution won't work in the back office in the APAC region [despite his team being invited to all previous meetings, and invited to collaborate on and review all the documents]. Action: Meeting Nomad to "assess the impact" of this [even though we already understand the impact. But this gives him something to do in his next meeting.]<br />
- All agreed that we should organise another meeting for next week to "review the actions from this meeting", and "see where we are" [which will be the same place we are now, but a week closer to the deadline].<br />
<br />
As I leave the meeting I speculate on how I might transition to the role of Inept Meeting Host, or Loudmouth and save myself the stress of trying to do a good job. Perhaps there's a work shadowing programme?<br />
<br />
Oh wait, I'm late for my next meeting. <br />
<br />
<br />
<br />
<br />
Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com0tag:blogger.com,1999:blog-7745338179376440175.post-19173193935447703212012-06-01T08:42:00.000+01:002012-06-01T08:42:16.337+01:00I no longer need to rememberSo I've got all this stuff in "the cloud". It's great, I don't need to worry about backing it up because some gigantic company has set up a trillion servers in vast glacier-chilled vaults to protect my electronic assets. In case of a nuclear world war my letter to British Gas will be safe and sound, as will the holiday snaps from Northumberland and the picture my friend sent me of the guy with the funny tattoos. These files are replicated hundreds of times to ensure they're not lost - and I have no doubt that future civilisations will be able to read my letter to British Gas and fully appreciate, even across the passage of centuries, how annoying that problem with my bill really was.<br />
<br />
This, for me, is the beauty of the cloud.<br />
<br />
Now of course I'm being slightly facetious - clearly cloud computing represents a huge leap forward in how we think about IT provisioning, and companies are increasingly considering it to reduce the financial overheads of maintaining hardware, and outsource the expertise required to properly manage scalability, security and so on.<br />
But for the home user, what really has changed (apart from the word Cloud popping up everywhere)? There are companies offering services and storage online, same as there were ten or fifteen years ago. They're just different services, and they now offer more storage.<br />
Take, for example, webmail. The fundamental tenets of cloud are true: it's stored and managed out there on the Internet. I need not concern myself with how or where. It will no doubt be replicated on many servers, and I neither know nor care which server is serving up my email about vi4gr4, or the eight hundred emails from Groupon I've received that day. <br />
<br />
But now, here's an idea. While online and social media companies continue to persuade us to share our every mindless thought or opinion, keep a note of everything and everyone we encounter (by the way, Evernote team: I am emphatically NOT going to start photographing everyone I meet. That is truly ridiculous), and store images of everything we see to share with our friends, the obvious extrapolation of that trend is this: <i>wire our brains up to the Internet to store our every experience into the cloud</i>. An online memory of everything we do, think, see or feel. CloudMemory (TM). (It's not really a trademark by the way, I just made it up - although I think there is a kind of mattress called this).<br />
<br />
It's not a very original idea - I'm sure it's featured in sci-fi movies, and Google are probably developing it as we speak, but consider the advantages below (there must be thousands, but these are the ones with the most profound implications for humankind):<br />
<br />
<ul>
<li>Never worry about printing out your train or flight confirmation again. Having looked at it once, forever after just look it up from CloudMemory.</li>
<li>"Who <i>is</i> that actor? I've definitely seen him in something recently. Oh wait, I can just retrieve it from my online memory using CloudMemory (TM)!"</li>
<li>Ever wonder what you just came upstairs to get? Just look it up on your iPhone using the CloudMemory app.</li>
<li>"Hey, remember that great time we had in Majorca?" "No. I no longer need to remember that time."</li>
</ul>
<br />
<br />
There are also some lesser advantages, such as:<br />
<br />
<ul>
<li>World peace could be brought about. I don't know how, but I'm pretty sure CloudMemory would help.</li>
<li>Crimes could be solved by allowing people to share certain memories with restricted people, to prove their alibi or version of events is true. It must have been difficult for Murdoch and Coulson, for instance, trying to help the Leveson inquiry but cruelly blighted by a failing memory. They could certainly have benefitted from CloudMemory.</li>
<li>2000 years from now no one will be able to claim the existence of visiting deity without providing proof in the form of a hyperlink to an archived online memory. "A reading from the first letter of Saint Phil to the inhabitants of Milton Keynes: And so it was that Bob Holness flew down from heaven in a hexagonal spaceship, to save our mortal souls. But don't take my word for it; see footage here: http://bit.ly/JJmHxd ". That sort of thing.</li>
</ul>
<br />
<br />
So you see that CloudMemory could be the next big thing (well, there might be some more big things first I guess, like the iPhone 5 with a slightly thinner case, or someone else offering online movie rentals).<br />
<br />
<hilarious ending gag><br />
So I'm off to file my patent for, erm, what was it again?<br />
</hilarious ending gag>Anonymoushttp://www.blogger.com/profile/13124121300772120626noreply@blogger.com0