www.jaxenter.com
Issue December 2010 | presented by
Java, Enterprise Architecture, Agile and Eclipse
Agile methods have entered the mainstream, but they don’t automatically create success. Product Owners play a key role in creating successful products. In this issue of JAXmag, we take a look at a whole range of topics
surrounding the agile ecosystem, from product owners to coaches, to the process itself. This and much more will also be covered at the upcoming JAX London, so make a note of the date: www.jaxlondon.com
Agile Day at JAX London
Agile Development People and Process Two Sides of the Same Coin
Agile Coaching Understanding The Role
Demystifying the Product Owner The Role in Scrum
Bad Code isn’t Technical Debt … … it’s an unhedged Call Option
#4
Editorial
Four Trends in Agile Software Development
Agile software development has come a long way since the late nineties when I discovered what is now known as agile practices. Back then even the term agile software development had not been coined. Today there are various agile approaches and methods to choose from with an ever-growing number of books, training courses, and instructional videos. This can make it hard to see what is central to agile development: teams that collaborate with stakeholders to create great products in a sustainable way. This edition of the JAXmag discusses four important agile software development trends: Karl Scotland explains why people are more important than processes introducing some of the foundations of Kanban. Rachel Davies discusses why coaching is key to become great at agile development. I write
about the importance of engaging the business and the product owner role to create great products, and Steve Freeman explains the idea of technical options highlighting the significance of software quality and craftsmanship. To learn more about the latest trends in agile software development, join me at the Agile Day at the next JAX London conference. The day takes palce on 11th April at the Park Plaza Victoria in London. It offers insights into what it takes to become agile and to succeed with agile methods sharing real-life stories and practical tips. Find out more at www.jaxlondon.com. I hope that reading this edition will be beneficial and enjoyable. May the agile force be with you. Roman Pichler
Index: People and Process
3
Two Sides of the Same Coin
Agile Coaching
6
Understanding The Role
Demystifying the Product Owner
9
The Role in Scrum
Bad Code isn’t Technical Debt …
11
… it’s an unhedged Call Option
Karl Scotland
www.JAXenter.com | December 2010
Rachel Davies
Roman Pichler
Steve Freeman
2
People and Process
People and Process are equally important
Two Sides of the Same Coin One of the most valued statements from the Agile Manifesto is “individuals and interactions over processes and tools”. This is often abbreviated to “people over process” with a common interpretation being that the human aspects of software development are the primary areas we should be focussing on for improvement. However, this is counter to the ideas of W. Edwards Deming, who said “a bad process will beat a good person every time”. Similarly, Don Reinertsen has said he prefers “people times process” because if either is zero, then the product is zero.
von Karl Scotland People and process are two sides of the same coin, both equally important in understanding how to improve capability to deliver valuable software.
People This side of the coin is about taking a group of people, who form a team in order to develop a capability. Peter Senge wrote in ‘The Fifth Discipline’ that “the fundamental learning units in an organisation are working teams (people who need one another to produce an outcome)”. Creating teams in this way allows people to iteratively learn about the way that they work so that they can incrementally develop their capability in order to improve the outcomes that they produce.
www.JAXenter.com | December 2010
This is the basis of all the popular Agile methods such as Scrum or Extreme Programming, which all recommend creating cross-functional and co-located teams, collaborating with high bandwidth communication. Thus, the people side suggests that forming outcome-focussed teams, rather than activity-focussed siloes, will result in an improvement.
Process This side of the coin is about taking a vision, which is developed into a product in order to deliver value. Mark Denne and Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about “an ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality”.
3
People and Process
Taking this approach means that a product will maximise its value through being iteratively refined piece by piece in order to incrementally deliver functionality. This is the basis of Lean approaches such as Kanban, which focuses on creating an explicit understanding of the process in order to learn how to deliver valuable pieces of software more effectively by modelling and visualising the work and associated policies. Concepts such as Minimal Marketable Features and User Stories help break down the work into smaller pieces. Thus, the process side suggests that continuously delivering small pieces of functionality with minimal delays, rather than waiting to release large batches of features, will result in an improvement.
Figure 1: People
People and Process It is when we put these two sides together that we can achieve significant improvement. The iterative loops of learning about both the team and the product link into each other, enabling product value to rapidly flow through capability teams. This is the development nirvana we are trying to reach. This model also gives some insight into why the “Waterfall” model, described by Winston Royce in his 1970 paper ‘Managing the Development of Large Software Systems’, has proved to be unsuccessful. It is not because the simple workflow described was inherently wrong, but because the workflow has typically been implemented with specialist siloes rather than capability teams, and with large rather than small batches. It is both sides of the coin that should be the focus of learning and improvement in order to help us on our journey to the nirvana of product development flow.
Figure 2: Process
Karl Scotland is a versatile software practitioner with over 15 years of experience covering development, project management, team leadership, coaching and training. For the last 10 years he has been successfully applying Agile methods, and most recently has been a pioneer and advocate of using Kanban Systems for software development. Currently an Agile Coach with Rally Software in the UK, Karl is a founding member of the Lean Software and Systems Consortium and the Limited WIP Society, and has previously championed Agile and Lean Thinking with the BBC, Yahoo! and EMC Consulting. Karl writes about his latest ideas on his blog at http://availagility.co.uk/ Figure 3: People and Process
Imprint Publisher Software & Support Media GmbH Editorial Office Address Geleitsstraße 14 60599 Frankfurt am Main Germany www.jaxenter.com Editor in Chief: Editors: Authors: Copy Editor: Creative Director: Layout:
Sebastian Meyen Jessica Thornsby, Claudia Fröhling Rachel Davies, Steve Freeman, Roman Pichler, Karl Scotland Nicole Bechtel Jens Mainz Patricia Schwesinger
www.JAXenter.com | December 2010
Sales Clerk: Mark Hazell +44 (0)20 7401 4845 markh@jaxlondon.com Entire contents copyright ©2010 Software & Support Media GmbH. All rights reserved. No part of this publication may be reproduced, redistributed, posted online, or reused by any means in any form, including print, electronic, photocopy, internal network, Web or any other method, without prior written permission of Software & Support Media GmbH The views expressed are solely those of the authors and do not reflect the views or position of their firm, any of their clients, or Publisher. Regarding the information, Publisher disclaims all warranties as to the accuracy, completeness, or adequacy of any information, and is not responsible for any errors, omissions, inadequacies, misuse, or the consequences of using any information provided by Publisher. Rights of disposal of rewarded articles belong to Publisher. All mentioned trademarks and service marks are copyrighted by their respective owners.
4
y
ar u n a th J ! 4 1 by ÂŁ100 r e t s Regi nd save a
11th – 13th April 2010 Park Plaza Victoria
Java, Enterprise, Web & Agile Mark your Calendar! All about the Java Ecosystem!
www.jaxlondon.com
Coaching
Understanding The Role
Agile Coach When I tell someone who hasn’t heard about agile software development that I work as an Agile Coach, they often assume that I work in physical fitness industry. Sadly, an agile coach is not going to help you get a washboard stomach! We work with software development teams to help them improve their performance and get the benefits of applying agile principles to their work.
by Rachel Davies, Agile Experience Ltd. I’ve worked as an agile coach for seven years now and still find that the role is not widely understood in the software industry. I hooked up with Liz Sedley to get more information out there about the role, the result is the first book on "Agile Coaching" [1]. Let's explore here what an agile coach does and why this role is so crucial to succeeding with Agile.
Becoming an agile coach Once upon a time, I was a software developer immersed in my own little world of software architecture and design. I was often oblivious to what my colleagues were working on
www.JAXenter.com | December 2010
until we attempted to integrate our work, and then entered a world of pain. How could we work more effectively to avoid interminable periods of rework? Luckily, I came across Extreme Programming (XP) in 2000. When you first hear about the practices of XP it sounds crazy; developers write tests before coding, they program in pairs, plan using index cards, and integrate software continuously. I joined an XP team to find out if this could really work. I was delighted to find that delivering software iteratively and working in closer collaboration makes the work more enjoyable as we learn together. XP includes the role of Coach who, according to Kent Beck [5], “watches the process as a whole and calls the
6
Coaching
team’s attention to impending problems or opportunities for improvement.” After three years working as a developer on an XP team, I chose to branch out and find work as an independent XP Coach. I was able to help teams get started with XP practices by drawing on my experience of implementing practices such as test-driven development and planning with user stories. Nowadays, I’ve broadened out and help teams use techniques from a wider set of Agile methods than XP. I won’t dwell on the pros and cons of Agile methodology here. However, I have learned that being a coach requires more than experience with agile practice. A coach helps a team implement changes and work more collaboratively, which can be a slow process because most people don’t like to change how they work. For this a coach must understand how to influence people and manage organisational change.
Contrasting agile coaching with existing roles In a nutshell, an agile coach helps teams grow strong in applying Agile [2] practice to their work. It takes time to adopt these changes so you can’t do this effectively as a "seagull consultant" or trainer who swoops in to deliver words of wisdom and then makes a sharp exit. You need to spend time with a team to help them to become more aware of their workflow and how to collaborate effectively. How is being a coach different from a team lead or project manager job role? Well, it’s not incompatible. The difference is that these roles have a wider set of project and company specific responsibilities, such as reporting progress, performance appraisals, etc. I notice that the pressure to deliver can distract from a focus on process improvement. Whereas, if you work solely as an agile coach, you can make this your sole focus because you don't have responsibility for project deliverables and administriva.
SUMMARY POINTS ■ Rachel Davies, co-author of first book on "Agile Coaching", explains the role an agile coach plays. ■ Examine how the role of agile coach compares with other roles, such as trainer, consultant, and manager. ■ Appreciate how agile coaching compares to coaching in other domains like sports and life-coaching. ■ Learn about the Hackman model of coaching interventions. ■ Discover how agile software design skills apply to agile coaching. ■ Understand the core skills that will help you become an effective agile coach.
More Infos More Infos on Agile Coaching can be found in Rachel’s book “Agile Couching” (by Rachel Davies and Liz Sedley ISBN: 978-1934356432)
www.JAXenter.com | December 2010
Being a coach is also different because it’s transitory role not tied into project duration. Your goal is for the team to become self-coaching and adept in applying agile then you move on. That doesn’t limit agile coaches to introducing agile into organizations and establishing new agile teams. The majority of the teams that I coach are already applying agile techniques and seek coaching because they want to boost their performance and proficiency in agile software development.
Drawing from other coaching fields You can see why people get confused about what agile coaching is because the term coaching is used more widely in non-software contexts. For instance, you may associate coaching with sports and also self-help techniques. Let's take a closer look at how these overlap with agile coaching. Business and life coaches usually work with individuals on a one-to-one basis. They help their “coachees” uncover personal goals and work out how to achieve them. As an agile coach, your primary focus is team performance towards company goals rather than the personal growth of individual team members. Of course, you’ll find that you often have to work with individuals to improve teamwork. So you can draw on techniques from lifecoaching to help people gain perspective on their work and open their eyes to new possibilities. However, I'd say that life-coaching skills are not sufficient. An agile coach has to bring a broader set of skills to a software development team than simply clarifying goals and working out required actions to achieve them. Sports coaches share the same focus of building a team that performs effectively. They require a deep knowledge of their sport and are often former players. They work on skills, tactics, and motivation. An agile coach wants to help teams with the same things — although techniques for building up physical sports skills don't really transfer into the world of software development. Instead, you can encourage developers on your team to improve as craftsmen and practice their code kata through coaching dojos [3]. So we see an agile coach can draw from both these coaching fields.
Understanding core skills The core skills for coaching agile teams are solid communication skills, such as listening, asking questions and giving feedback. To engage with the whole team, you must go beyond one-to-one conversations and enable effective team conversations. So meeting design and facilitation are also core skills for agile coaches. This year I've run workshops with coaches at Agile and XP conferences to introduce Richard Hackman's model for coaching interventions [4]. He defines a coaching intervention as “any action that seeks to minimize process losses or to foster process gains.” He goes on to identify three categories of coaching intervention: • Educational interventions improve understanding and skills on the team. • Consultative interventions foster process improvement by helping the team become more aware of their (mindless) habits. • Motivational interventions improve effort by building shared commitment and minimizing free-riding.
7
Coaching
The big eye-opener for most agile coaches, who took part in these workshops, is that they usually focus on educating teams in agile practices and how to improve their agile process but they neglect motivation. Notice where team members are coasting along and not pulling their weight, now explore why. Think about ways that you can re-engage each team member. You can make a start by bringing them together to establish shared goals that they believe are achievable and open up team discussion of what’s in it for them.
Where software design experience helps You might be surprised to learn that many of the skills that we acquire as a software developers also come in handy as coaches. Much of our work is to help teams “debug” their agile process by making them more visible and inspecting what’s revealed. We follow the work through the team from concept to delivery and help the team to become more aware of inputs and outputs along the way. We prompt them to get their brains in gear and find ways they can adapt their processes to raise and handle exceptions smoothly. Object-oriented thinking also helps us see opportunities for refactoring team process. Our team needs to get the coupling and cohesion of the work right to improve the flow of software deliveries through the team. Many activities in the Agile lifecycle can be decoupled. For example, a planning meeting can be broken into different sections that are run as separate meetings; doing this helps keeps the meetings shorter and more focussed. We can also apply the Once-And-Only-Once principle to remove duplication of information which when spread around a plethora of tools (such as wikis, defect tracker, index cards, spreadsheets) can be a source of confusion and lead to important aspects of requirements being missed. When you make the right information easy to find then decisions can be made swiftly by the team.
Bringing it all together When you're engaged as an agile coach, don't be surprised if your clients have some strange ideas about what an agi-
www.JAXenter.com | December 2010
le coach does. They may expect all coaching to happen in a series of meetings far away from the team. You’ll need to educate them about the role and explain that spending time with the team while they’re at work is an essential part of coaching. Before you get started, hone your communications skills for one-to-one conversations and team meetings. Draw from the fields of life-coaching and sports coaching for ways to unleash intrinsic motivation. Now you can apply your existing experience in software development, to lead teams to debug and refactor their agile process. If all that seems like a tall-order, start simple. Engage your current team by making their process more visible and then reflect with them on what’s revealed.
References [1] "Agile Coaching" by Rachel Davies and Liz Sedley ISBN: 978-1934356432 [2] Agile Manifesto: http://www.agilemanifesto.org/principles.html [3] "Leading Teams: Setting the Stage for Great Performances" by J. Richard Hackman ISBN: 978-1578513338 [4] Coding Dojo: http://www.codingdojo.org [5] “Extreme Programming Explained” by Kent Beck ISBN: 978-0201616415 [6] <iframe src="http://player.vimeo.com/video/14500114?byline=0&amp;port rait=0&amp;color=A8CC45" width="400" height="300" frameborder="0"></ iframe><p><a href="http://vimeo.com/14500114">Rachel Davies - Coaching Agile Teams</a> from <a href="http://vimeo.com/user3233384">Maria Diaconu</a> on <a href="http://vimeo.com">Vimeo</a>.</p> [7] <a href="http://vimeo.com/14500114" target="_blank">Coaching Agile Teams</a> video of talk at Open Agile Romania<br/>
Rachel Davies works in the UK as an independent agile coach helping teams adopt and improve their agile delivery capability. Her new book "Agile Coaching" shares many practical tips that can help you take your teams to the next level. Rachel has supported the agile community as a former chair of the Agile Alliance and as an organizer of many Agile conferences. This year she is the general chair for XP2011 conference in Madrid. Find out more information from her website at http://www.agilexp.com and follow her blog at http://agilecoach.typepad.com/
8
Scrum
The Role of product owners in Scrum
Demystifying the Product Owner This article discusses the role of the product owner in Scrum. The role has attracted plenty of interest and controversy. Some people believe it rebrands the traditional product manager. Others think it is a team lead role or Scrum’s take on the project manager. None of theses views are completely true, but there is some truth in them.
By Roman Pichler, romanpichler.com In a nutshell, the product owner is responsible for the success of the product. This usually requires the product owner to lead product discovery, to help identify and describe requirements, and to ensure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping, decide what functionality is provided by a release, carry out release planning, and answer questions from the team, review work results, and collaborate with customers, users and other stakeholders. “The Product Owner’s focus is on return on investment (ROI),” writes Ken Schwaber in his book Agile Project Management with Scrum (2004, 18). If we follow this advice, then product owners will have to look after products over an extended period of time – at least until the ROI can be determined – if not after the product’s entire lifecycle. Having one person in charge from bringing a new product to life, to discontinuing the product has many benefits; it creates continuity and eliminates wasteful handoffs, delays and defects.
Many Facets The different responsibilities make the product owner a challenging and multi-faceted role that shares some of the responsibilities traditionally attributed to a product marketer,
www.JAXenter.com | December 2010
product manager and project manager. But make no mistake: As tempting as it may be to compare the product owner to traditional roles, it’s fundamentally flawed. The product owner is a genuinely new role that cuts across existing job and department boundaries. The specific shape of the role is context-sensitive: It depends on the nature of the product, the stage of the product lifecycle, and the size of the project, among other factors. For example, the product owner responsible for a new product consisting of software, hardware, and mechanics will need different competencies than someone who is leading the effort to enhance a web application. Similarly, a product owner working with a large Scrum project will require different skills than one collaborating with only one or two teams.
Collaboration Being the product owner is no solo act. As a member of the Scrum team, the product owner closely works with the ScrumMaster and the team. But the individual also collaborates with the customers, users and other stakeholders thereby bridging the gap between the market and development. The product owner needs the support from the other Scrum team members, for instance, to discover, describe, prioritise and detail product backlog items. Otherwise, the individual will end up being overworked, and the knowledge, creativity, and experience of the ScrumMaster and the team are wasted.
9
Scrum
Finding the Right Individual
For commercial products, the product owner is typically a customer representative, such as a product manager or marketer. An actual customer tends to assume the role when the product is being developed for a specific organisation, for instance, an external client who requires a new data warehouse solution or an internal client like the marketing department asking for a web site update. I have worked with customers, users, business line managers, product managers, project managers, business analysts, and architects who filled the product owner role well in the given circumstances. Even CEOs can make great product owners. I often get asked what characteristics a product owner should exhibit. Even though the answer depends on the context, the successful product owners I have worked with share the attributes discussed below. As transitioning into the product owner role is a learning process for the individual and the organisation, playing the role effectively may require patience and perseverance.
management. The product owner is the voice of the customer, communicating customer needs and requirements connecting “the suits” with “the techies.” Sometimes this means saying no and other times negotiating a compromise.
Empowered and Committed The product owner must have enough authority and the right level of management sponsorship to lead the development effort and to align stakeholders. An empowered product owner is essential for leading the effort to create a great product. The product owner must have the proper decision-making authority—from finding the right team members to deciding which functionality is delivered as part of the release. The individual must be someone who can be entrusted with a budget and at the same time has the ability to create a work environment that fosters creativity and innovation. Finally, the product owner must be committed to the development effort.
Available and Qualified
The product owner is a visionary who can envision the final product and communicate the vision. But the product owner is also a doer who sees the vision through to completion. This includes describing requirements, closely collaborating with the team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress. As an entrepreneur, the product owner facilitates creativity; encourages innovation; and is comfortable with change, ambiguity, debate, conflict, playfulness, experimentation, and informed risk taking.
The product owner must be available and qualified to do a great job. Being the product owner is usually a full-time job. It is important to give product owners enough time to sustainably carry out their responsibilities. If the individual is overworked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately qualified usually requires an intimate understanding of the customer and the market, being passionate about the user experience, and the ability to communicate needs and describe requirements, to manage a budget, to guide a development project, and to be comfortable working with a cross-functional, self-organising team.
Leader and Team Player
Summary
As the individual responsible for the product’s success, the product owner provides guidance and direction for everyone involved in the development effort and ensures that tough decisions are made. For instance, should the launch date be postponed or should less functionality be delivered? At the same time, the product owner must be a team player who relies on close collaboration with the other Scrum team members, yet has no formal authority over them. You can think of the product owner as primus inter pares, first among peers, regarding the product.
The product owner is a fascinating and challenging role. It plays a key part in creating great products with Scrum, and it is the cornerstone of establishing Scrum in the enterprise. “Until recently, I viewed this relationship [between product management and development] as one of many changes in a Scrum adoption. I now view it as the most critical change, the lynchpin of the adoption. If this change is successful, the use of Scrum will persist and benefits will increase. If the change isn’t successful, the use of Scrum in your enterprise might well unravel,” writes Ken Schwaber in his book Scrum and the Enterprise (2007, 85). Given that the product owner is a genuinely new role, it is not surprising that playing it can be challenging. But it is well worth the effort.
Visionary and Doer
Communicator and Negotiator The product owner must be an effective communicator and negotiator. The individual communicates with and aligns different parties, including customers, users, development and engineering, marketing, sales, service, operations, and
More Infos More Infors on Agile Product Management can be found in Roman's book "Agile Product Management with Scrum" (ISBN: 978-0321605788)
Roman Pichler helps companies create great products by providing consulting, coaching and training in agile product management and Scrum. Roman has ten years experience in helping companies embrace agile methods, and a long track record in teaching and coaching product owners and product managers, business analysts, ScrumMasters, managers, and teams. He is the author of several books on Scrum including “Agile Product Management with Scrum,” the product owner's guide to developing successful products with Scrum. Product ownership and agile product management form a focal point of Roman's work.
Links & Literatur [1] http://www.se-radio.net/2010/05/episode-161-agile-product-managementwith-roman-pichler/
www.JAXenter.com | December 2010
10
Software Culture
Changing metaphors
Bad code isn’t Technical Debt ... ... it's an unhedged Call Option. This is all Chris Matts‘ idea [1]. He realised that the problem with the “Technical Debt” metaphor is that for managers debt can be a good thing. Executives can be required to take on more debt because it makes the finances work better, it might even be encouraged by tax breaks. This is not the same debt as your personal credit card. Chris came up with a better metaphor, the Call Option.
von Steve Freeman I “write” a Call Option [2] when I sell someone the right, but not the obligation, to buy in the future an agreed quantity of something at a price that is fixed now. So, for a payment now, I agree to sell you 10,000 chocolate santas at 56 pence each, at any time up to 10th December. You’re prepared to pay the premium because you want to know that you’ll have santas in your stores at a price you can sell. From my side, if the price of the santas stays low, I get to keep your payment and I’m ahead. But, I also run the risk of having to provide these santas when the price has rocketed to 72 pence. I can protect myself by making arrangements with another party to acquire them at 56 pence or less, or by actually having them in stock. Or, I can take a chance and just collect the premium. This is called an unhedged, or “Naked” [3], Call. In the financial world this is risky because it has unlimited downside, I have to supply the santas whatever they cost me to provide. Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up. On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.
www.JAXenter.com | December 2010
Even if it is more expensive to do things cleanly (and I’m not convinced of that beyond a two-week horizon), it’s also less risky. A messy system is full of unhedged calls, each of which can cost an unpredictable amount should they ever be exercised. We’ve all seen what this can do in the financial markets, and the scary thing is that failure, if it comes, can be sudden—everything is fine until it isn’t. I’ve seen a few systems which are just too hard to change to keep up with the competition and the owners are in real trouble. So that makes refactoring like buying an option too. I pay a premium now so that I have more choices about where I might take the code later. This is a mundane and obvious activity in many aspects of business—although not, it seems, software development. I don’t need to spend this money if I know exactly what will happen, if I have perfect knowledge of the relevant parts of the future, but I don’t recall when I last saw this happen. So, the next time you have to deal with implausible delivery dates, don’t talk about Technical Debt. Debt is predictable and can be managed, it’s just another tool. Try talking about an Unhedged Call. Now all we need is a way to price Code Smells [4]. Steve Freeman is an independent consultant specializing in Agile software development. A founder member of the London Extreme Tuesday Club, he was chair of the first XPDay and is a frequent organizer and presenter at international conferences. Steve has worked in a variety of organizations, from writing shrink-wrap software for IBM, to prototyping for major research laboratories. Steve has a Ph.D. from Cambridge University, and degrees in statistics and music. Steve is based in London, UK.
Links [1] http://abc.truemesh.com/ [2] http://en.wikipedia.org/wiki/Call_option [3] http://en.wikipedia.org/wiki/Naked_call [4] This text was originally published here: http://www.m3p.co.uk/ blog/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/
11