tag:blogger.com,1999:blog-1233188886650665712024-03-04T20:46:16.116-08:00alphaITjournalThe practitioner's journal of maximizing yield from IT investments.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.comBlogger41125tag:blogger.com,1999:blog-123318888665066571.post-47912935503270208242010-01-23T13:52:00.000-08:002010-02-19T20:53:40.923-08:00ITIL is considered essential, but does it internalize transaction cost?<p>By John Kehoe - <em> 19 February 2010</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s1600-h/kehoe.jpg"><img style="MARGIN: 0px 10px 10px 0px; WIDTH: 60px; FLOAT: left; HEIGHT: 74px" id="BLOGGER_PHOTO_ID_5343652952609688434" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s200/kehoe.jpg" /></a>I have slept though many an ITIL briefing. There is something about those process charts that just cause me to glaze over; I must have been thinking about the cost of applying ITIL. It is a business process and process must be paid for. Does it earn its keep, or does it waste money on needless feedback loops for monitoring the quality of printing services. Certainly, it should only be applied in a supporting role for revenue facing activities. If so, why is there no mention of application management and revenue alignment? Transaction Performance Management (TPM) fits that niche nicely.<br /><br />My first encounter with ITIL occurred some years back at a companywide sales kickoff for a $5B software company. We didn’t sell ITIL software, but we wanted all the consultants, system engineers and account executives fluent in ITIL and position our products in that context. We had a very nice, engaging and intelligent fellow for an instructor. He had impeccable credentials and came from a name brand global consultancy.<br /><br />He introduced the history of ITIL, which was my first warning of impending doom (and eye glazing). ITIL was created by UK bureaucrats over a decade ago. It details exacting process and frameworks for IT organizations. The idea being that process can bring order to chaos. Its process is well suited for change management and run books, but there are parts that are just plain silly. Do we need a TQM style approach with elaborate feedback loops for printing, file, network services and availability? Most IT activities are utilities. There are two variables of concern. One, is the service available? Two, is it performing? There is no need for detailed statistics, they don’t matter.<br /><br />Another concern about ITIL is cost. ITIL is a process and process costs money. I’ve not seen ITIL performance statistics tied to revenue in any shop I’ve visited. There are claims of increased output, reports showing three digit improvements in productivity, downtime reports to two decimal places. We’ll that is great news. How much did it cost? How much revenue did it contribute? Did we apply resources efficiently? ITIL doesn’t answer those questions.<br /><br />What is missing from ITIL (other than affordable documentation)? Performance management is the key piece. There is no mention of Transaction Performance Management. By using a TPM approach one can quantify end user experience, determine root cause degradation and use an ingrained feedback loop. Why do this, to focus effort real business impact.<br /><br />Let’s lay out a scenario. End users are complaining about order entry. We hit our run books and start the triage. We hit the server and application stats. We review the log files. We have each team investigate their respective technology with their tools. Maybe there are some sophisticated workflows to follow. Noticed what happened. Where is the end user? Where is the business alignment? A formal framework around dodgy process is a dodgy formal framework. Worse still, it does nothing to resolve the performance issue.<br /><br />Now let’s keep the eye on the transaction. We see what, who and where it is coming from. Maybe it’s a slow network link. Then it’s a last mile problem and we needn’t bother the developers or DBA’s. Maybe there something unique about the transactions, we see that and notify the middleware team. You see where I’m going with this. You see all the waits for transactions down to the storage array. You see the characteristics of the transactions and where and how they break. This is Transaction Performance Management. One keeps an eye on all of the transactions over the whole of the architecture in context of the business, user and technologies. This is what ITIL lacks, a tight, comprehensive approach to the performance of the business and underlying technologies.<br /><br />Recently I worked with a very clever group of consultants. Their specialty is mapping business transactions to risk, and then mapping that risk to revenue. The old style of doing that is fixing a cost to an outage. For example, I might lose $60 for every minute I’m out of service. For two 9’s (88 hours), I’ll lose $315k. For four 9’s (52 minutes), I lose $3,100. Is it worth investing $300k to reduce this number? Ah, that is the question isn’t it. We don’t have enough information to justify this. Where does the $60 come from? Is it a semi- factually derived value (SWAG)? What transactions are in play? What happens if the transactions are slow as opposed to unavailable? What opportunity costs are incurred?<br /><br /><strong>Are you investing in the right application? How do you know?</strong><br /><br />To answer those questions, my consulting friends built a sophisticated model based on how business transactions are executed and the revenue associated with each. They then added their secret risk models and viola; my customer can map their transaction data to her transaction risk model. She can see exactly where transactions are breaking down, have sliding scales of performance impact to risk and understand the opportunity cost for a given outage or SLO (Service Level Objective) breach.<br /><br />This is a compelling approach. You can now make focused expenditure judgments based on transactional risk. You can immediately see the impact of a transaction change to the business. You can’t have a tighter and more focused feedback loop than that.<br /><br />This is why the TPM approach makes so much sense. It ties business transactions to risk in a way that ITIL or ITSM or Six Sigma cannot do. In doing so it complements the structured approach, except TPM is the process that that pays for itself and builds business value.<br /><br /><hr /><br /><strong>About John Kehoe:</strong> John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at <a href="mailto:exoticproblems@gmail.com">exoticproblems@gmail.com</a>.John Kehoehttp://www.blogger.com/profile/03246846478788199263noreply@blogger.com3tag:blogger.com,1999:blog-123318888665066571.post-91649669242963287342009-06-04T22:58:00.000-07:002009-06-04T23:00:51.650-07:00Ververs - Generation Y R.I.P.? Not so Fast!<p>by Carl Ververs - <em>4 June 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglQET-x95oDd83mia_XJAp6a2hAyZjnZ-jLpxSEKI-uMTRVCuEaA1a7g3FJwDnzXIXxKVn-G1Qf1Lg5apO5WtV41ylOKMPQ5D8TrUm6umXSSlUoirbzsaI5qKAGuy-wHVD59e-Bp2UDEY/s1600-h/ververs.jpg"><img id="BLOGGER_PHOTO_ID_5343639697043836450" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglQET-x95oDd83mia_XJAp6a2hAyZjnZ-jLpxSEKI-uMTRVCuEaA1a7g3FJwDnzXIXxKVn-G1Qf1Lg5apO5WtV41ylOKMPQ5D8TrUm6umXSSlUoirbzsaI5qKAGuy-wHVD59e-Bp2UDEY/s200/ververs.jpg" border="0" /></a> <p>Gleefully, various business publications are proclaiming the death of Generation-Y and their irreverent, anti-business shenanigans. Sure, their weird, hyper-connected ways got an unlikely candidate elected as president. But it just CAN’T BE that those lazy Twittering Facebookers get away with it while the rest of us had to pipe down, see our heroes stripped of their crowns and watch helplessly as our iconic businesses were exposed as mismanaged or fraudulent.</p><p>Or can it?</p><p>In unapologetically pro-business, anti-Millennial magazines, their editors have not hesitated to take an advance on the humbling impact of the economy on Gen-Y. The Economist, a more objective but no less pro-business periodical, did a 180, usually writing that Gen-Y’s attitudes had to change but later acknowledging that their preferred way of working should be embraced (<a href="http://www.economist.com/opinion/displaystory.cfm?story_id=12853955">Managing the Facebookers</a>). In a subsequent article, they wrote that because of the downturn, Millennials took a humbler tone when interviewing, but were not giving up on many of their other traits (<a href="http://www.economist.com/business/displaystory.cfm?story_id=12863573">Gen-Y goes to work</a>).</p><p>Their uniqueness is waning because they are being squashed by economic realities. But we would do well to not overlook the positives from the Gen-Y mindset.</p><p>Everybody is saying, "The fun is over" and that the Gen-Y people need to figure out that work means suffering. Fear has us desiring a simpler and more predictable way of living and working, so we're seeing people revert to the behaviors they know. But the way of work and life of yore may not apply in this new world order. In fact, long before we get to any sense of "stability" again we're going to have to deal with a lot of volatility: Just look at the wild swings of the world markets. Ironically, Gen-Y’s orientation on life may be quite applicable now. They are possibly better prepared to deal with volatility and change. Per <a href="http://www.thebigmoney.com/articles/judgments/2009/03/11/young-and-jobless">this article</a> on The Big Money, Generation Y is taking the whole recession in stride.</p><p><strong>“The Network Is The Company”</strong></p><p>Gen Y’s leverage continues to be that employers need them more than they need employers. They do not have to make a killing financially and certainly will not sacrifice their health and lifestyle for a firm. Since companies cannot be trusted to take care of them and keep them employed, they cut companies off at the pass and keep a pool of opportunities open, in case the boss does not behave or the company does not come through. Advice for Gen-X: do the same. We can learn something from Gen Y here.</p><p>The downside of the lack of loyalty is that they can be hired away easily, are overly suspicious of authority and management and subsequently put a company’s return on investment in training and on-boarding at risk. All this may drive up labor costs even if salaries stagnate. The positive side of this is that they can be hired away easily from somewhere else, their volatility requires them to learn how to come up to speed rapidly at new jobs (which makes them deployable in other functions within your firm as well) and keeps your management honest and on their toes.</p><p>It will be interesting to see how Gen-Y ends up viewing wealth and finance. They have witnessed up-close the meltdown of the US financial establishment and the evaporating of personal wealth. Where Gen-X grew up with the notion that you’d be fine as long as you bought a house and kept investing in your 401(K), Gen-Y has come to understand the uncertain and volatile value of capital and assets. Home-ownership now has a whiff akin to teenage pregnancy: a liability with unclear upside.</p><p>A Millennial does not buy into the 80’s craze of self-help success books such as “Seven Habits of Effective People” because the people quoted as examples are either dead, in jail or in rehab. A few others have publicly abandoned their beliefs (such as “greed is good”). Of course I’m exaggerating, but it is clear that the personas and lifestyles the Boomers and to an even greater extent Gen-X were oohing and aahing over have no meaning for Gen-Y. What good is money if it corrupts you? They certainly learned the Faustian lesson that there truly is such a thing as selling your soul.</p><p>Race and socio-economic strata have also ceased to have meaning for Gen-Y. A mother told me how her daughter dismissed her questions about which race the people in her class were as irrelevant and racist.</p><p>As workplace expert Tamara Erickson points out in her book <a href="http://www.amazon.com/Plugged-Generation-Guide-Thriving-Work/dp/1422120600">Plugged In: The Generation Y Guide to Thriving at Work</a>, Millennials love to learn, and they’re good at it. With the right guidance they may turn out to be incredibly effective employees.</p><br /><hr /><br /><p><strong>About Carl Ververs</strong>: Carl has been a business transformer through technology since the start of his career two decades ago. Always at the vanguard of new thinking and creative application of systems, he built CRM systems, used SOA and applied Agile techniques well before they were named.</p><p>Carl's technical expertise lies mainly in high-performance computing for derivatives trading and business process management. His background spans a wide spectrum, including business application specialist, hierarchical storage system architect, customer management systems designer, trading operations manager, Agile project Management coach, SOA practice lead, PMO/QA director and deputy CIO. Carl is an avid musician and composer, computer graphics artist and geopolitical pundit. He lives in Chicago with his wife and son.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-49436338875912698602009-05-13T22:51:00.000-07:002009-06-04T22:58:23.838-07:00Pettit - Governing IT Restructure<p>By Ross Pettit - <em>13 May 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s1600-h/rjp1.jpg"><img id="BLOGGER_PHOTO_ID_5343624959897658850" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s200/rjp1.jpg" border="0" /></a> In a <a href="http://alphaitjournal.blogspot.com/2009/02/pettit-restructuring-it-making-in.html">previous article</a> on change management, I outlined the urgent need to restructure IT. Corporate revenues have plummeted and demand will take a long time to recover. Capital structures have buckled and <a href="http://online.wsj.com/article/SB124200067135005117.html">capital markets are on life support</a>. Business operations are being scrutinized for inefficiency and businesses are deflating their cost structures through salary reductions, unpaid leave and RIFs. With this as a backdrop, it comes as no surprise that <a href="http://www.ibm.com/ibm/ideasfromibm/us/smartplanet/topics/businessproductivity/20090504/index1.shtml">91% of CEOs say they need to restructure the way their organizations work</a>. IT, being core to business operations, faces restructure as well. <p>The restructuring we need to do in IT has less to do with org charts and budgets that direct effort, and more to do with behaviours that get results. Testing must be a team responsibility, automated and integrated into everybody’s daily activity. Our business partners must be continuously involved in solution development, to enable continuous change management and adaptive project management. IT Governance must be non-burdensome and non-invasive, tracking and connecting a variety of indicators. We have the experiences, examples, patterns, tools and technologies to do all of these things today, but bringing this about requires very basic change in how people get things done.</p><p>So how do we restructure? We follow the usual change management formula – figure out where we’re at, where we want to be, and how we’ll get there – but we pay less attention less to the tasks of restructuring, and more to the results we achieve.</p><p><strong>Step 1: Define a Vision for Operations</strong></p><p>The first thing to do is define a vision of operations. That vision needs to be explicitly spelled out. For example, part of our organizational vision might include an expectation such as: "solutions are subjected continuously to quality gatekeepers that validate technical, functional and non-functional completeness." Simple, assertive statements like this clearly communicate expectations for how work is done.</p><p>But more than just the “what” of the vision, we also need to make clear “why” we want to do these things. That means communicating the business impact we expect by doing these things. It also means we draw a line between “what we do” and “what it accomplishes.” For example, suppose we’re trying to get solutions into production faster. We can make it clear that we expect we’ll do that by reducing rework, having fewer non-value-added tasks, and having higher bandwidth communication among people in teams. We expect our operational vision will bring each of these about. For example, continuously executing quality gatekeepers will catch defects sooner and reduce rework, and also eliminate non-value-added tasks such as manual solution packaging and industrial-scale manual testing.</p><p>In expressing why we want to do these things, we must be specific: for example, as a result of this restructure, we expect we will be able to deliver new solutions to production every 20 business days, or we expect to reduce IT spend on solution delivery by 25%. The purpose of any restructure isn’t a new structure, but results, so we must use the language of results.</p><p><strong>Step 2: Assess Current State</strong></p><p>With a very specific vision in hand, we now assess the current state of how work is done, so we know the gap between where we’re at and where we want to be. This requires critically assessing both how work is done, as well as how it is not done. This generally involves artifact review, but more importantly involves facilitated group discussion among people in different roles - PMs, business people, developers, QA analysts and so forth - to identify practices and patterns.</p><p>This assessment is the single most important activity in a restructuring initiative. If we get this piece wrong, nothing else – not the vision, not the plan, not the monitoring – will matter, because all of our actions will be based on false data.</p><p>One of the most common mistakes organizations make in restructuring is to try to self-assess where they're at today. Self-assessments are inherently inflationary, because any type of assessment has performance ramifications. They make people uncomfortable, and can be outright confrontational. Self-assessing is usually hypersensitive to the politics of a situation, which creates a tremendous risk of distorting objectivity.</p><p>This means we should look to bring in somebody from the outside to perform the assessment. Having no personal investment to protect or political baggage to lug around will give them an independent perspective. In addition to looking critically at how things are done today, they can ascertain the viability of the vision, and recognize potential (and potentially undesirable) outcomes that may result from this restructure. But this takes the right facilitator: it calls for somebody experienced in business, management and technology who understands IT and can quickly understand a business context. The right person will not only waste little time in ramping-up, they’ll bring relevant experience into the process.</p><p>Another risk during assessment is denial that there are any real shortcomings in the way work is done. To overcome a false sense of operational excellence, start the assessment process by talking to its customers: perform a customer satisfaction survey or <a href="http://agilemanager.blogspot.com/2006/11/leading-indicator-of-it-relevance.html">Net Promoter</a> score of IT solution users. An unvarnished external opinion makes it a lot harder to gloss over operational shortcomings, and gets people focused on results (“how do we improve customer satisfaction”) instead blame (“you’re making it impossible for me to do my job.”)</p><p><strong>Step 3: Define a Restructuring Plan</strong></p><p>With current and future state now defined, we next determine the plan that will get us there. A behaviourally-centric reorganization is going to require a change in “muscle memory.” Change doesn't happen overnight, so we need to figure out the stages of organizational evolution that will allow new patterns of work to take root and become durable under stress. While we can look to <a href="http://tinyurl.com/agile-project-management"><span style="TEXT-DECORATION: underline"><span style="color:#0000ff;">patterns of organizational change</span></span></a> to help us sequence the activities of our change initiative, the plan will be largely derived from experience. There will be some “low hanging fruit” as well as some significant challenges in the plan. We can get on immediately with the obvious stuff, but before we get too far down a path of execution, we need to come face to face with our competencies and deficiencies and call in outside help. For example, if we get blindsided by late-stage project failures, we shouldn't expect that our PMs can self-source a change to new project management practices. Recognizing the areas where we need expertise and engaging it at the right time of our restructuring initiative will get us through the change process with minimum blowback.</p><p><strong>Step 4: Monitor the Restructuring</strong></p><p>Finally, while we’re in process of restructuring, we need a way to monitor that we are making meaningful progress. Ultimately, we need to be cognizant of our results: are we closer to our goal of achiving faster time-to-market, or reduced operating costs? But those take time to materialize, and we need to scrutinize the underlying factors of our success or failure. Ongoing customer satisfaction or Net Promoter scores that we initiated during the assessment phase can help ascertain whether we're on the right track, but again, this isn't an elemental enough data point. Restructuring milestones such as “roles defined and staffed” and “reporting structures created” are insufficient, because they're task-based and not results-based. What we're looking for are ways to monitor behavioural change. </p><p>To do this, it helps to have a model, such as the <a href="http://tinyurl.com/agile-maturity-model">Agile Maturity Model</a>. Having been applied at a number of IT organizations in a variety of industries, the AMM allows us to consistently frame current and target organizational behaviours, map actions that will change those behaviours, and monitor how well we’re taking to those behaviours over time. </p><p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggBTDLGmBm9sHG4FmOm2MapTmGClPY_kdRW95XTW-C0U_MzuH1hE5dSiYWHORZErck5lWD8krlSAgoe1ErZFwEhVi1U1bJy1UPwpYRoCXDwDFdjJQMzGN6FO5Wkw1VVe509CXLo1quMRA/s1600-h/AMM+radar.JPG"><img id="BLOGGER_PHOTO_ID_5343718311596786962" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 263px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggBTDLGmBm9sHG4FmOm2MapTmGClPY_kdRW95XTW-C0U_MzuH1hE5dSiYWHORZErck5lWD8krlSAgoe1ErZFwEhVi1U1bJy1UPwpYRoCXDwDFdjJQMzGN6FO5Wkw1VVe509CXLo1quMRA/s400/AMM+radar.JPG" border="0" /></a> <p>By using a framework that allows us to consistently and frequently assess how work is performed, we get a pretty good idea as to whether we're increasingly doing things that will engender success. It also allows us to scrutinize where we're deficient, communicate the impact that deficiency is having on our goals, and take corrective action.</p><p>You can get started with some of the AMM concepts by running <a href="http://agileassessments.thoughtworks.com/">an online profiling tool</a> for your own organization or project. This will give you a picture of how you are structurally aligned today and some insight into where you might have opportunities to change.</p><p>While we don’t yet know the regulatory, capital, competitive and commercial fallout from the financial collapse and economic recession, we do know that "business as usual" is off the table. While this makes day-to-day execution challenging, it presents us with an opportunity to recast and remake IT. By focusing on results as opposed to effort, we make IT a transparent, efficient, responsive and collaborative contributor to the business. This makes IT less a supplier of technical services, and more an engaged business partner, putting it firmly at the forefront of corporate leadership. At a time when companies are navigating uncertain waters, better to be sharing responsibility at the helm than relegated to the engine room below deck.</p><br /><hr /><br /><strong>About Ross Pettit:</strong> Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active <a href="http://agilemanager.blogspot.com/"><strong>blogger</strong></a> on topics of IT management, governance and innovation. He is also the editor of <a href="http://www.alphaitjournal.com/categories/20080616"><strong>alphaITjournal.com</strong></a>.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-92107165619818559702009-04-29T22:48:00.000-07:002009-06-04T22:51:08.152-07:00Breidenbach - Getting to a Hire Level, Part Deux<p>By Kevin E. Breidenbach <em>29 April 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj10-sHRQUPKCoJmAxwywU0W8iCvEPUuebkr1g9nIgExQ0kvssZUcuFHvNSnnxP-GKELK9UBsZdmeT8Vq4e2au8XQY5kHVO43p6YyA7BOWqeaJa8v0q40z-Sw4QvrFzsbYBJkH0FcIp0bo/s1600-h/breidenbach.JPG"><img id="BLOGGER_PHOTO_ID_5343679938901742706" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj10-sHRQUPKCoJmAxwywU0W8iCvEPUuebkr1g9nIgExQ0kvssZUcuFHvNSnnxP-GKELK9UBsZdmeT8Vq4e2au8XQY5kHVO43p6YyA7BOWqeaJa8v0q40z-Sw4QvrFzsbYBJkH0FcIp0bo/s200/breidenbach.JPG" border="0" /></a> <p>So, having read <a href="http://alphaitjournal.blogspot.com/2009/04/breidenbach-getting-to-hire-level-part.html">the first part of this series</a>, you’ve looked over your organization and found that you have a good Agile process in place, quality people working for you, and a good base of subject matter experts. It turns out that the 80 hour weeks your team has been working are caused by the runaway success of your business and your team’s enthusiasm for accepting more and more stories and pushing new functionality out the door. Yes, I know, very Obamistic, but it could happen!</p><p>So what do the rest of us do?</p><p><strong>Creating a Hiring Process</strong></p><p>You could just throw together a job specification and rely on search firms or job boards. You could also ask the neighbor kid to prepare and file your tax return for you. Search firms do find good people, but you can’t outsource your responsibility: at the end of the day it’s <em>your</em> responsibility to find the <em>right</em> person or people.</p><p><strong><em>Marketing the Position</em></strong></p><p>The first thing most job candidates see is a published job description and position requirements. This is an extremely important artifact: not only does it describe what you are looking for, but it also advertises the job role. If you want the best people you need to entice them into entering your recruitment process, and what you advertise is an important part of achieving that. </p><p>If you know that a developer will have the opportunity to do greenfield development, put it in the description. If they are going to get the chance to work with some of the best minds in the business, tell them. Starting to see where this is going? This is Marketing 101.</p><p>The job requirements should be specific, but not give away too much information. For instance, suppose we know that we definitely want someone with experience of working in an Agile development team. So say just that, but don’t get into specifics such as: “must use test driven development” or “has pair programmed with Ward Cunningham”. The candidate (and sometimes the search firm) will add whatever you have specified to the resume. This is why you have to thoughtfully drill down into their experience during the interview: if they’ve never really worked in an Agile team, you'll know about it soon enough.</p><p><strong><em>Improve Your Interview Success Batting Average</em></strong></p><p>Every person that you bring in for an interview costs both money and time. It reduces productivity during the time they are visiting, and is an overhead cost to your business. This is true of both face-to-face and phone interviews. To make best use of increasingly scarce time, you need to make sure you are bringing in the right people in the first place.</p><p><em>Test, Test, Test</em></p><p>While you could rely on a search firm or recruiter to only supply you with resumes of people that fit your job description, we all know that rarely happens. Excuses like “<a href="http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/">JMX </a>and <a href="http://java.sun.com/products/jms/">JMS </a>are the same, right?” just don’t cut it, and in the past I’ve been known to stop dealing with search firms who do things like that. But there is an easier way to know you're investing time in the right candidates: testing!</p><p>No matter what your HR department tells you, there is nothing wrong with testing candidates. Providing it is done fairly and each person applying for a particular role is given the same tests with the same constraints, you’re good to go. </p><p>My favorite test is to send a programming exercise to candidates before they are brought in for an interview. Give them a set number of days to complete it, and eagerly await the results. This will instantly give you an idea of who to bring in: if they send you one file of code, but no build script or unit tests, the resume goes in the bin. If they do send in what you consider to be a complete response, you’ve now got some very specific talking points for the interview. Quiz them on their design decisions, the patterns they used, and so forth. You’ll soon know if they actually produced the code they submitted, or had somebody write it for them.</p><p><strong><em>The Day of the Interviews</em></strong></p><p>So you’ve perused the resume, checked out the programming exercise and you’ve decided to bring the candidate in for an interview. Tell the candidate that they should expect to be at your location from between 1 and <em>n</em> hours, where <em>n</em> depends on how many face to face interviews you have planned.</p><p><em>...And more tests</em></p><p>Still, you still don't want to invest your staff's time interviewing a candidate if he or she is not going to be up to the task. So, once a candidate is on-site, the first thing I do is give each candidate a couple of written tests. </p><p>I have some terrible code that compiles and works, but is inefficient and poorly written. One test I ask them to do is to make the code more efficient. A second test is a basic design quiz that asks how a developer could refactor code to make it easier to unit test. Each test should take 10 minutes, but I give them 20 minutes total and let them decide how to spend the time. It doesn't take long to review the results. If a candidate fails to perform in this exercise, I won’t waste time with an interview. </p><p>The next phase is a quick pair programming exercise. First, let the candidate take to the keyboard for a while, and then sit back and be in the partner’s chair. This will give you some idea at how well he communicates, his ease at pairing and how he performs under pressure. Again, if he’s not a good fit, thank him for taking his time and send him on his way. Your interviewers can get on with their work, and they’ve not been disrupted by a poor candidate.</p><p><em>Face to Face Interviews</em></p><p>At this point, you're ready to interview. Send in your “A’s” to make sure you’re only hiring “A’s”. They should stick to questions in their area of expertise: business people shouldn’t ask technical questions as they will look unprofessional and may dissuade a good candidate from joining. However, the technical people should concentrate on technology applicable to the domain they are working in: it may be wonderful that somebody can design an elevator control system, but it's of theoretical value only if you’re building trading platforms.</p><p><strong><em>Discuss the Candidate</em></strong></p><p>Get everyone together to discuss the candidates who make it through the face-to-face round. The decision must not be about egos, but facts: one person who takes a dislike to a candidate shouldn’t have the decision making ability to throw him out. Also, the hiring manager shouldn’t be able to over-ride the team decision. There can be a lot of nefarious motivations in hiring decisions. I’ve seen people hired solely because they were friends with the hiring manager, and it always ends in tears. </p><p><strong>The Golden Rule of Hiring</strong></p><p>Hiring is not an easy task and it shouldn’t be taken lightly. As much as you need a development process in place, you must first have a formal hiring process in place. Remember also that in advertising for new hires, you are advertising your company as well. Being unprofessional through the hiring process will turn away top candidates, even in the current economic climate. Above all else, remember the golden rule: treat the process and the candidate as you would like to be treated. One way or another, all the tests, interviews and advertising - all the activities you perform in the hiring process - communicate how much respect is valued in your organization. Your next hire will respond to that most of all.</p><br /><hr /><br /><strong>About Kevin Breidenbach:</strong> Kevin has a BSc in computer science and over 15 years of development experience. He has worked primarily in finance but has taken a few brief expeditions into .com and product development. Having professionally worked with assembly languages, C++, Java and .Net he's now concentrating on dynamic languages such as Ruby and functional languages like Erlang and F#. His agile experience began about 4 years ago. Since that time, he has a serious allergic reaction to waterfall and CMM.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com2tag:blogger.com,1999:blog-123318888665066571.post-62141540093852343432009-04-23T22:44:00.000-07:002009-06-04T22:47:45.328-07:00Cross - Bridging the Gap<p>by Brad Cross - <em>23 April 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s1600-h/bcross3.JPG"><img id="BLOGGER_PHOTO_ID_5343646599935290498" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s200/bcross3.JPG" border="0" /></a> <p>From the feedback I've received for my technical balance sheet series, I've identified two gaps in how people understand the concept. The first gap is that this approach requires somebody to be simultaneously knowledgeable in finance and software. The second gap is that it is unclear how you can adopt some of these ideas with a very small initial investment.</p><p>The technical balance sheet ideas are simple and cheap to try out. They can help you make cross-disciplinary trade-offs about software, finance, and operations. This can involve technical people who know almost nothing about finance, finance people who know almost nothing about technical work, and business operations and project management people who may not be strong in either finance or software.</p><p>So, bridging the first gap is easy: you don't need to have a double PhD in finance and computer science in order to understand these ideas. Building software costs money, going slower costs more money, and technical debt makes you go slower. If you have a lot of assets, but those assets are over-leveraged with debt, you can end up cash flow negative with negative assets. On the other hand, if you have no debt and no assets, you also have nothing. So the other side of the equation is to build software that has high asset value. Focus on the aspects of your systems that have the highest return on investment, and do so without borrowing through shortcuts and sloppiness. The technical balance sheet is just a way to give you a mental model for thinking about the trade-offs.</p><p>This leads into the second point: this is cheap to adopt. You don't have to spend a lot of time and money to try this out. The <a href="http://alphaitjournal.blogspot.com/2008/08/cross-technical-liabilities-malignant.html">first article on gathering metrics</a> for technical liabilities may have been a bit intimidating because it was not clear how to create a quick balance sheet for a project unless they made a significant up-front investment. Hopefully that was cleared up in the explanation of the approach in the <a href="http://alphaitjournal.blogspot.com/2009/03/cross-field-guide-for-applying.html">field guide article</a>.</p><p>You can quickly assemble a prototype balance sheet with just a few metrics that are really simple to round up. I did this on one project in about an hour by harvesting the metrics that were already available via the coverage bundle and <a href="http://pmd.sourceforge.net/">PMD</a>, all of which were already running in their build.</p><p>Bootstrapping a balance sheet is not about spending a lot of time putting together a bunch of overly complex tables and metrics. You can do a few simple exercises, look at the numbers, and see if it helps you think about your trade-offs and plan of action.</p><p>As an example, on a project I was working on last year I saw that we spent 40-50% of story points on a couple areas of plumbing. After some investigation, it turned out that there was some heavyweight architecture and design in place that I was able to eliminate pretty quickly. On top of it, a lot of the code could be replaced by open source components. I also saw that that the most valuable components as far as the business was concerned were in terrible shape (bad design, lots of bugs, low test coverage.) Right away, I could see that we were over-investing in maintaining plumbing and under-investing into the parts that generate the real cash flows. </p><p>This scenario is common: an over-investment on low quality infrastructure coupled with an under-investment in the parts of the system that support the business in generating actual cash flows. The solution is to figure out how to reduce your ongoing investment into plumbing, while simultaneously focusing on how to increase your investment in the cash flow generating parts of your systems. With minimal effort, the technical balance sheet can expose where these over or under investments are. It communicates in terms everybody can understand (e.g., we get value from this area of the code, we do not get value from that area of the code.) Applying a technical balance sheet to your project can make it clear to each member of the team where their attention should not be, as well as where it needs to be, to maximize the business impact of your project.</p><br /><hr /><br /><strong>About Brad Cross:</strong> Brad is a programmer.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-37808021676021530302009-04-16T22:40:00.000-07:002009-06-04T22:44:02.212-07:00Breidenbach - Getting to a Hire Level, Part I<p>By Kevin E. Breidenbach - <em>16 April 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj10-sHRQUPKCoJmAxwywU0W8iCvEPUuebkr1g9nIgExQ0kvssZUcuFHvNSnnxP-GKELK9UBsZdmeT8Vq4e2au8XQY5kHVO43p6YyA7BOWqeaJa8v0q40z-Sw4QvrFzsbYBJkH0FcIp0bo/s1600-h/breidenbach.JPG"><img id="BLOGGER_PHOTO_ID_5343679938901742706" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj10-sHRQUPKCoJmAxwywU0W8iCvEPUuebkr1g9nIgExQ0kvssZUcuFHvNSnnxP-GKELK9UBsZdmeT8Vq4e2au8XQY5kHVO43p6YyA7BOWqeaJa8v0q40z-Sw4QvrFzsbYBJkH0FcIp0bo/s200/breidenbach.JPG" border="0" /></a> <p>I’ve been involved in recruiting technology people for some time. Although not a recruiter, my role has often included the hiring (and less fun, the firing) of staff for a number of different organizations. I now find myself in a technology group – and when I say "group," I mean "me" – that has to embark on the task of building a team that can supply the technological solutions that the business partners need. I plan to use the knowledge I’ve learned over the past umpteen years to the job, and thought that it might be fun to impart that information on all of you.</p><p><strong>Common Mistakes Made When Hiring People</strong></p><p><em>Hiring for Hiring's Sake</em></p><p>Your team has been working 80-hour weeks for the past 6 months when suddenly you’re given an enormous budget to hire more people. (I know – a dream in this economy, but it's been known to happen.) Suddenly the recruitment engine kicks in full swing. Job requirements are posted, search firms are given their marching orders, and resumes flood in. Your team doubles in size in just a few months, but you’re still working 80-hour weeks. What on earth went wrong?</p><p>Did anybody look at why your team was working 80-hour weeks in the first place? Could it be that they have no process? Could it be that there was insufficient domain knowledge? Could it be that your team has a number of “net negative” people? If any of those are true, then just hiring new people is not going to solve the problem. More than likely, it'll just make it worse. </p><p>If you don’t have a process in place, new people aren’t going to be able to contribute that quickly and will get lost in the sea of misguided effort. If you don’t have sufficient domain knowledge, you'll have nobody to identify who the right people are to hire, and then teach them what they need to know once they start. If you don’t identify and remove net negative developers – people who contribute less than the work they create for other people to do – you don’t eliminate disruption within the team. This all may seem obvious, but all too often, nobody looks at the root cause of a problem before they set out to solve it by hiring.</p><p><em>Who's Doing the Hiring</em></p><p>A very wise person once told me of the “As hire As, Bs hire Cs” conjecture, and I’ve seen it in practice. Someone at the top of their game - an "A" person - is more likely to hire someone who has equal or better skills than they have, than they are to hire someone who is crap at their job. This is because highly competent people don’t see hiring other competent people as a threat, but as a way to learn. Incompetent people see hiring competent people as a short path to being laid off. Think about it: would Rex Grossman hire Tom Brady when they could be competing for QB? </p><p>An “A” candidate isn’t necessarily somebody strong in a particular skill (unless that is a requirement). It could be someone with a desire to learn, who spends their spare time researching technologies, and who has confidence in themselves. Aptitude and attitude, more than skill or knowledge, are what separate the top-tier from the middling performers.</p><p><em>Do I Really Need a Specialist?</em></p><p>I’ve heard excuses from developers at all levels about why things don't get done. “There’s nobody to design the database”; “We desperately need a GUI developer”; “My wife just had a baby and I’m on paternity leave”. Okay, that last one is valid, provided the guy is actually married and does have a newborn. </p><p>Seriously though, many of those excuses come from net negative developers who are content with knowing what they know, prefering the comfort of <a href="http://alphaitjournal.blogspot.com/2008/10/breidenbach-grain-and-icbms.html">working in a silo</a> to learning and growing. If they have no interest in growing their personal capabilities, do they really have any interest in growing your organization? </p><p>Think about the real need you have for different specialists. For example, do you have enough database work to warrant hiring a full time database administrator? Do you really need a specialist GUI developer when you only have two screens to produce? How much use will you really get from him, versus how much work he’ll manufacture for himself to do? Could a developer who’s eager to learn, working with some outside expertise for a bit of coaching and auditing, get the work done more efficiently? A small team of poly-skilled generalists will always outperform a large team of specialists in silos.</p><p>The fact is that some specialists only want to advance their specialization. If you don’t have that much work for them, they’ll be expensive ornaments at best, or create a perpetual (and costly) maintenance legacy at worst.</p><p><strong>Before Hiring</strong></p><p>Before you start hiring, get your house in order. Make sure that you really need new people, not that you have the wrong people, or have a complete lack of process. If you do hire, make sure the right people are doing the interviewing. Finally, make sure that any specialist you add will make your team stronger than it would be from having people with a wider collection of skills. The business will appreciate it if you don’t use their entire budget on useless hires. They’ll also appreciate it if your team gets more stuff done, instead of having new faces to blame.</p><p></p><br /><hr /><br /><strong>About Kevin Breidenbach:</strong> Kevin has a BSc in computer science and over 15 years of development experience. He has worked primarily in finance but has taken a few brief expeditions into .com and product development. Having professionally worked with assembly languages, C++, Java and .Net he's now concentrating on dynamic languages such as Ruby and functional languages like Erlang and F#. His agile experience began about 4 years ago. Since that time, he has a serious allergic reaction to waterfall and CMM.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-20891219574206910202009-04-01T22:33:00.000-07:002009-06-04T22:40:11.601-07:00Cross - A Field Guide for Applying Technical Financial Statements, Part II<p>By Brad Cross - <em>1 April 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s1600-h/bcross3.JPG"><img id="BLOGGER_PHOTO_ID_5343646599935290498" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s200/bcross3.JPG" border="0" /></a> <p>This article is the second in a series on putting the technical balance sheet to work. If you haven't done so already, you will want to read the <a href="http://alphaitjournal.blogspot.com/2009/03/cross-field-guide-for-applying.html">first in the series</a>.</p><p><strong>Taking Action to Increase Equity</strong></p><p>So, we've bootstrapped our balance sheet. Now, how to we get some of these ideas into our decision making process? If we notice something that is harming our owner's equity, how do we actually put that knowledge into practice?</p><p>It is critical to have code metrics that are actionable. A lot of tools will show you fancy charts, tables and diagrams, but few of these visual representations are actionable from a technical perspective. You need to be able to identify prioritized lists of actions. For example, <a href="http://www.redhillconsulting.com.au/products/simian/">Simian</a> or <a href="http://pmd.sourceforge.net/cpd.html">CPD</a> will sort the list of code duplication by worst offenders. Clearly, your first action is to tackle the worst offenders. If you see that your highest bug counts and lowest test coverage is in one of your most valuable components, then working on the robustness of that component is a clear action item. Often you can find a few monolithic classes where many of the issues occur; refactoring these while bringing them under test can be a simple way to achieve a radical change in your equity for that component. </p><p>Once you have defined a list of actions prioritized by impact on equity in your most valuable components, you are ready to start increasing your equity. There are other important and practical technical considerations to consider, however. As we discussed in the article on <a href="http://alphaitjournal.blogspot.com/2008/12/cross-cost-of-carry-versus-cost-of.html">cost of carry vs. cost of switching</a> you should be mindful of the impact of encapsulation and the dependencies among components. <strong>Start at the least dependent, but most depended upon, parts of the system</strong>: the leaf nodes of the dependency graph. </p><p>There are a couple of ways to tackle your list of actions. One is through big-bang refactoring or "clean up" efforts, and the other is through a more incremental "as you touch it" approach.</p><p>I typically prefer the incremental approach. I continue working as normal, and make the assumption that when I do a new piece of work in a target area, I am going to invest more time because I will be implementing actions from my prioritized list for increasing equity.</p><p>This incremental approach works very nicely most of the time and avoids big-bang "let's stop and refactor the world" efforts, which tend to suspend new development and rarely seem to work out well. That said, there are circumstances when it is appropriate to invest in testing and other infrastructure, because these investments can make your incremental efforts more effective. You will often run into structural issues that cause trouble. For example, you may have some monolithic piece of code in the system that everything is tightly coupled to. If this is holding up incremental progress, breaking this code apart in order to restructure the dependencies can be a sound investment. At the moment, I don't have any way to quantify this - you just need to have some people around who have significant experience working on large systems and restructuring efforts and have a pragmatic view and a good instinct for when this sort of thing is required.</p><p><strong>Refactor, Rewrite or Replace?</strong></p><p>In the article on the <a href="http://alphaitjournal.blogspot.com/2008/12/cross-cost-of-carry-versus-cost-of.html">cost of carry vs. cost of switching</a>, we made a passing mention of migration strategy.</p><p><table cellspacing="15" cellpadding="15" border="0"><tbody><tr><td>Cost of switching is the cost associated with your mitigation strategy. When indebted code is an impediment to sustaining and evolving the functionality of your project, your mitigation strategy is how you go about transitioning away from indebted code in order to reduce or eliminate the impediments. This can entail completely replacing a component with another component, partially replacing a component, or simply small incremental refactorings that accumulate over time. Switching costs are impacted by the size and scope of the component you are replacing, the time you have to spend to find and evaluate commercial and open source alternatives, time spent on custom modifications to the replacement, and time spent on migrating infrastructure - for instance, migrating or mapping user data after switching to a different persistence technology.</td></tr></tbody></table></p><p>Let's look at migration strategy in more concrete detail. </p><p>When we talk about migration strategy, it is usually related to refactoring, rewriting, or replacing.</p><p>First, your system needs to be structured in such a way that you make trade-offs at the component level and not system-wide. I discussed this at the very beginning of this series. It doesn't make sense to look at metrics and valuations at the component level unless you can actually trade-off at that level.</p><p>Components with a low asset value (easy to substitute) and high liabilities are good candidates for replacing or rewriting. Often you can combine replacing and rewriting by finding a way to write thin custom layers around open source components that can replace these parts of the system. This typically requires a bit of refactoring as well, in order to allow other components to use the new component, so you often end up using a bit of each approach.</p><p>Components with a high asset value (hard to substitute) and high liabilities are candidates for refactoring. Sometimes you can pull parts of these components out into new components that can be replaced or rewritten, but often this wont get you far. Typically these high value components are the core domain logic. Often the logic is more sophisticated and if you introduce new bugs while refactoring, they may be difficult to track down as they can result in subtle incorrectness rather than blatant crashing, exceptions and such. Careful and incremental refactoring is usually the way to go.</p><p>Finally, sometimes there are good reasons to rewrite an entire application stack. This might be appropriate, for example, if you are switching to an entirely new runtime and technology stack. Sometimes this is called re-platforming. Don't rewrite in the same language and technology stack just because you have written a crappy code base and it is too fragile to change anymore. When you abandon ship in that case, you lose the value of all the lessons you will learn from refactoring it. Sometimes, the best approach is to <a href="http://bradfordcross.blogspot.com/2009/03/refactoring-your-way-to-rewrite.html">refactor your way to a rewrite</a>.</p><p><strong>Bridging the Gap</strong></p><p>In the next piece, we will bridge the gap between finance and engineering. A big part of bridging this gap is noticing how each side tends to gravitate toward the asset and liability side of the balance sheet, respectively. This is where the technical balance sheet shines: allowing you to reduce ongoing investment into the plumbing aspects of your system and increase investment into your "special sauce."</p><br /><hr /><br /><strong>About Brad Cross:</strong> Brad is a programmer.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-75236537728633760182009-03-25T22:28:00.000-07:002009-06-04T22:39:05.893-07:00Cross - A Field Guide for Applying Technical Financial Statements, Part I<p>By Brad Cross - <em>25 March 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s1600-h/bcross3.JPG"><img id="BLOGGER_PHOTO_ID_5343646599935290498" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s200/bcross3.JPG" border="0" /></a> <p>So far, we have discussed a number of ways of applying financial models to software projects. We explored liabilities as an estimate of a project's technical debt. We explored assets as an estimate of the business value of software components. We explored techniques for computing equity as a function of assets and liabilities. We explored cost of carry and cost of switching as proxies for cash flows. We concluded by exploring techniques for framing tradeoff decisions based on equity and cash flow analysis. </p><p>The purpose of weighing assets against liabilities and cost of carry against cost of switching is to manage components of software projects like financial portfolios - assessing each component on its risk vs. return. The objective is to have a functional model for framing technical and business decisions about software. These models are not prescriptive. The purpose of the series so far has been to introduce the technical, financial, and process concepts.</p><p>Now that we understand these concepts, how do we put this into practice? </p><p>First of all, if your project is a complete mess, then collecting a bunch of metrics and rigorously applying financial concepts may not be appropriate at all. If you have only a handful of tests, then there really isn't much point in a careful analysis of test coverage and the distinction between unit test coverage and system test coverage. If your system is in really bad shape, your problems are often painfully obvious. That said, when it seems difficult to know where to start, the balance sheet model can help you pinpoint the worst problems and target the components that need the most attention.</p><p>I have applied this balance sheet approach in a number of different ways on my projects. I’ve used it to decide whether I should rewrite, refactor or replace un-maintainable components that carried too much technical debt. I’ve used it to inform estimates of effort: if an enhancement required modifying a component with high technical liabilities, I knew it was probably going to take longer. I’ve used it to prioritize work to maximize owner's equity by increasing priority of work in high-asset components and de-prioritizing or seeking open-source replacements for low-asset components.</p><p>I'm sure there are other ways to apply this model to software projects. For instance, if you have many different projects, programs, or business areas, you could apply this approach at different levels of granularity in the business. You could also use this way of thinking to frame decisions about green-field projects; even at startups. In fact a classic startup mistake is to pile on too much technical debt in an effort to go faster, which results in going slower, and ultimately leads to hitting a brick wall.</p><p><strong>Step 1: Choose your metrics that define your debt</strong></p><p>I recommend sticking to a pragmatic, lightweight spirit with this technical balance sheet approach. Use what you can get on the cheap - without much time investment. On one project, we already had access to <a href="http://www.atlassian.com/software/clover/">clover</a>, so we were able to mine its metrics "for free". We used these metrics to build the initial prototype of our balance sheet in an hour.</p><p>On my last project, we built a mind map (see below) of what we considered to be interesting metrics. We assembled the entire team to discuss what we thought were the most important aspects of the technical quality of the system (i.e. the most costly liabilities) and then identified which liabilities were measurable with current open source tools. It is interesting to note here that some aspects I typically evaluate are missing - such as code duplication. The team never mentioned this as one of the top concerns during this session.</p><p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIZXKj2TIkLSajPDDVTodIogfD3ynYw8F7bejmcLOqASiO4iq8NkShQFFJNE1MAZG-JK49NieD7ajq86Te2-HxD_MByf9mBDCUTwqLcTTzhjKjHdNNkbh4m1Q6jUk1OJ3eW-_aaUXExjI/s1600-h/Cross+Field+Guide+Mindmap3.JPG"><img id="BLOGGER_PHOTO_ID_5343711770934851378" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 120px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIZXKj2TIkLSajPDDVTodIogfD3ynYw8F7bejmcLOqASiO4iq8NkShQFFJNE1MAZG-JK49NieD7ajq86Te2-HxD_MByf9mBDCUTwqLcTTzhjKjHdNNkbh4m1Q6jUk1OJ3eW-_aaUXExjI/s400/Cross+Field+Guide+Mindmap3.JPG" border="0" /></a></p><p>Whatever metrics you choose, it is critical that they are actionable. A lot of tools will show you fancy charts, tables and diagrams, but few of these visual representations are actionable. You need to be able to identify prioritized lists of actions. For example, Simian or CPD will sort the list of code duplication by worst offenders; your obvious first action is to tackle the worst offenders. If you see that your highest bug counts and lowest test coverage is in one of your most valuable components, then working on the robustness of that component is a clear action item. Often you can find a few monolithic classes where many of the issues occur; refactoring these while bringing them under test can be a simple way to achieve a radical change in your equity for that component.</p><p><strong>Step 2: Compute your financials by functional area</strong></p><p>Here's a recap of our journey through the examples used in our discussions:</p><p>In the article on measuring <a href="http://www.alphaitjournal.com/articles/20080807">technical liabilities</a>, we constructed a table using a few simple and common metrics as indicators of technical indebtedness.</p><p style="TEXT-ALIGN: center"><table id="j:j0" cellspacing="0" cellpadding="0" border="1"><tbody id="j:j00"><tr id="j:j01"><td id="j:j02" valign="top" width="115" style="color:#003366;"><p id="j:j03" align="center"><span style="color:#000000;"><strong>Functional Area</strong><span style="font-size:0;"></span></span></p></td><td id="j:j05" valign="top" width="60" style="color:#003366;"><p id="j:j06"><span style="color:#000000;"><strong>FX Cop</strong><span style="font-size:0;"></span></span></p></td><td id="j:j08" valign="top" width="72" style="color:#003366;"><p id="j:j09"><span style="color:#000000;"><strong>Coverage</strong><span style="font-size:0;"></span></span></p></td><td id="j:j011" valign="top" width="54" style="color:#003366;"><p id="j:j012"><span style="color:#ffffff;"><strong><span style="color:#000000;">Lin</span><span style="color:#000000;">es</span></strong><span style="font-size:0;"></span></span></p></td><td id="j:j014" valign="top" width="84" style="color:#003366;"><p id="j:j015"><span style="color:#ffffff;"><strong><span style="color:#000000;">Duplication</span></strong><span style="font-size:0;"></span></span></p></td><td id="j:j017" valign="top" width="102" style="color:#003366;"><p id="j:j018" align="center"><span style="color:#000000;"><strong>% Duplication</strong><span style="font-size:0;"></span></span></p></td></tr><tr id="j:j020"><td id="j:j021" valign="top" width="115"><p id="j:j022" align="center">Brokers</p></td><td id="j:j024" valign="top" width="60"><p id="j:j025">139</p></td><td id="j:j027" valign="top" width="72"><p id="j:j028">1%</p></td><td id="j:j030" valign="top" width="54"><p id="j:j031">2984</p></td><td id="j:j033" valign="top" width="84"><p id="j:j034">234</p></td><td id="j:j036" valign="top" width="102"><p id="j:j037">8%</p></td></tr><tr id="j:j039"><td id="j:j040" valign="top" width="115"><p id="j:j041">Data</p></td><td id="j:j043" valign="top" width="60"><p id="j:j044">52</p></td><td id="j:j046" valign="top" width="72"><p id="j:j047">31%</p></td><td id="j:j049" valign="top" width="54"><p id="j:j050">1450</p></td><td id="j:j052" valign="top" width="84"><p id="j:j053">297</p></td><td id="j:j055" valign="top" width="102"><p id="j:j056">20%</p></td></tr><tr id="j:j058"><td id="j:j059" valign="top" width="115"><p id="j:j060">DataProviders</p></td><td id="j:j062" valign="top" width="60"><p id="j:j063">59</p></td><td id="j:j065" valign="top" width="72"><p id="j:j066">1%</p></td><td id="j:j068" valign="top" width="54"><p id="j:j069">1210</p></td><td id="j:j071" valign="top" width="84"><p id="j:j072">78</p></td><td id="j:j074" valign="top" width="102"><p id="j:j075">6%</p></td></tr><tr id="j:j077"><td id="j:j078" valign="top" width="115"><p id="j:j079">DataServer</p></td><td id="j:j081" valign="top" width="60"><p id="j:j082">27</p></td><td id="j:j084" valign="top" width="72"><p id="j:j085">48%</p></td><td id="j:j087" valign="top" width="54"><p id="j:j088">1489</p></td><td id="j:j090" valign="top" width="84"><p id="j:j091">40</p></td><td id="j:j093" valign="top" width="102"><p id="j:j094">3%</p></td></tr><tr id="j:j096"><td id="j:j097" valign="top" width="115"><p id="j:j098">Execution</p></td><td id="j:j0100" valign="top" width="60"><p id="j:j0101">7</p></td><td id="j:j0103" valign="top" width="72"><p id="j:j0104">48%</p></td><td id="j:j0106" valign="top" width="54"><p id="j:j0107">618</p></td><td id="j:j0109" valign="top" width="84"><p id="j:j0110">0</p></td><td id="j:j0112" valign="top" width="102"><p id="j:j0113">0%</p></td></tr><tr id="j:j0115"><td id="j:j0116" valign="top" width="115"><p id="j:j0117">FIX</p></td><td id="j:j0119" valign="top" width="60"><p id="j:j0120">27</p></td><td id="j:j0122" valign="top" width="72"><p id="j:j0123">1%</p></td><td id="j:j0125" valign="top" width="54"><p id="j:j0126">48484</p></td><td id="j:j0128" valign="top" width="84"><p id="j:j0129">39337</p></td><td id="j:j0131" valign="top" width="102"><p id="j:j0132">81%</p></td></tr><tr id="j:j0134"><td id="j:j0135" valign="top" width="115"><p id="j:j0136">Instruments</p></td><td id="j:j0138" valign="top" width="60"><p id="j:j0139">133</p></td><td id="j:j0141" valign="top" width="72"><p id="j:j0142">55%</p></td><td id="j:j0144" valign="top" width="54"><p id="j:j0145">12896</p></td><td id="j:j0147" valign="top" width="84"><p id="j:j0148">714</p></td><td id="j:j0150" valign="top" width="102"><p id="j:j0151">6%</p></td></tr><tr id="j:j0153"><td id="j:j0154" valign="top" width="115"><p id="j:j0155">Mathematics</p></td><td id="j:j0157" valign="top" width="60"><p id="j:j0158">77</p></td><td id="j:j0160" valign="top" width="72"><p id="j:j0161">56%</p></td><td id="j:j0163" valign="top" width="54"><p id="j:j0164">2551</p></td><td id="j:j0166" valign="top" width="84"><p id="j:j0167">205</p></td><td id="j:j0169" valign="top" width="102"><p id="j:j0170">8%</p></td></tr><tr id="j:j0172"><td id="j:j0173" valign="top" width="115"><p id="j:j0174">Optimization</p></td><td id="j:j0176" valign="top" width="60"><p id="j:j0177">25</p></td><td id="j:j0179" valign="top" width="72"><p id="j:j0180">60%</p></td><td id="j:j0182" valign="top" width="54"><p id="j:j0183">305</p></td><td id="j:j0185" valign="top" width="84"><p id="j:j0186">26</p></td><td id="j:j0188" valign="top" width="102"><p id="j:j0189">9%</p></td></tr><tr id="j:j0191"><td id="j:j0192" valign="top" width="115"><p id="j:j0193">Performance</p></td><td id="j:j0195" valign="top" width="60"><p id="j:j0196">2</p></td><td id="j:j0198" valign="top" width="72"><p id="j:j0199">73%</p></td><td id="j:j0201" valign="top" width="54"><p id="j:j0202">134</p></td><td id="j:j0204" valign="top" width="84"><p id="j:j0205">0</p></td><td id="j:j0207" valign="top" width="102"><p id="j:j0208">0%</p></td></tr><tr id="j:j0210"><td id="j:j0211" valign="top" width="115"><p id="j:j0212">Providers</p></td><td id="j:j0214" valign="top" width="60"><p id="j:j0215">36</p></td><td id="j:j0217" valign="top" width="72"><p id="j:j0218">47%</p></td><td id="j:j0220" valign="top" width="54"><p id="j:j0221">707</p></td><td id="j:j0223" valign="top" width="84"><p id="j:j0224">42</p></td><td id="j:j0226" valign="top" width="102"><p id="j:j0227">6%</p></td></tr><tr id="j:j0229"><td id="j:j0230" valign="top" width="115"><p id="j:j0231">Simulation</p></td><td id="j:j0233" valign="top" width="60"><p id="j:j0234">20</p></td><td id="j:j0236" valign="top" width="72"><p id="j:j0237">77%</p></td><td id="j:j0239" valign="top" width="54"><p id="j:j0240">241</p></td><td id="j:j0242" valign="top" width="84"><p id="j:j0243">0</p></td><td id="j:j0245" valign="top" width="102"><p id="j:j0246">0%</p></td></tr><tr id="j:j0248"><td id="j:j0249" valign="top" width="115"><p id="j:j0250">Trading</p></td><td id="j:j0252" valign="top" width="60"><p id="j:j0253">54</p></td><td id="j:j0255" valign="top" width="72"><p id="j:j0256">50%</p></td><td id="j:j0258" valign="top" width="54"><p id="j:j0259">2955</p></td><td id="j:j0261" valign="top" width="84"><p id="j:j0262">472</p></td><td id="j:j0264" valign="top" width="102"><p id="j:j0265">16%</p></td></tr><tr id="j:j0267"><td id="j:j0268" valign="top" width="115"><p id="j:j0269">TradingLibrary</p></td><td id="j:j0271" valign="top" width="60"><p id="j:j0272">66</p></td><td id="j:j0274" valign="top" width="72"><p id="j:j0275">29%</p></td><td id="j:j0277" valign="top" width="54"><p id="j:j0278">7035</p></td><td id="j:j0280" valign="top" width="84"><p id="j:j0281">1674</p></td><td id="j:j0283" valign="top" width="102"><p id="j:j0284">24%</p></td></tr></tbody></table></p><p>Next, in the article on measuring <a href="http://www.alphaitjournal.com/articles/20081106">assets and intangibles</a>, we talked about using substitutability as a proxy for asset valuation in order to consolidate a basket of concrete metrics into an abstract relative metric.</p><p style="TEXT-ALIGN: center"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td style="color:#003366;"></td><td style="color:#003366;"><p><strong><span style="color:#000000;">Module</span></strong></p></td><td style="color:#003366;"><p><strong><span style="color:#000000;">Substitutibility</span></strong></p></td><td style="color:#003366;"><p></p></td><td bordercolor="#003366"><p><strong></strong></p></td><td style="color:#003366;"><p></p></td><td style="color:#003366;"><p><strong><span style="color:#000000;">Module</span></strong></p></td><td style="COLOR: #003366"><p><strong><span style="color:#000000;">Substitutibility</span></strong></p></td><td color="#003366"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Brokers</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Mathematics</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Data</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Optimization</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>DataProviders</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Performance</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>DataServer</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Providers</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Execution</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Simulation</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>FIX</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Trading</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Instruments</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>TradingLogic</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>4</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p></p></td></tr></tbody></table></p><p>In the piece on <a href="http://www.alphaitjournal.com/articles/20081113">technical equity</a>, we show to transform our table of metrics for technical liabilities into a number that can be reasonably compared with the asset value of each component in order to derive a rough number representing technical equity and how leveraged each component is.</p><p style="TEXT-ALIGN: center"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td color="#003366"><p><strong><span style="color:#ffffff;"><span style="color:#000000;">Component</span> </span></strong></p></td><td color="#003366"><p><strong><span style="color:#000000;">Assets </span></strong></p></td><td color="#003366"><p><strong><span style="color:#000000;">Liabilities </span></strong></p></td><td style="COLOR: #003366"><p><strong><span style="color:#000000;">Equity </span></strong></p></td><td style="COLOR: #003366"><p><strong><span style="color:#ffffff;"><span style="color:#000000;">Leverage</span> </span></strong></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Brokers</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3 </p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>-1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity </p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Data</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>-1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity </p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>DataProviders</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>-1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>DataServer</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Execution</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>FIX</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>4</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>-3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Instruments</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Mathematics</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Optimization</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Performance</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Providers</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Simulation</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>Trading</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p>TradingLogic</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>4</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p>4</p></td></tr></tbody></table></p><p>Finally, in the article on <a href="http://alphaitjournal.blogspot.com/2008/12/cross-cost-of-carry-versus-cost-of.html">cost of carry vs. cost of switching</a>, we discussed thinking about tradeoff decisions in terms of cash flows when considering paying down more or less principal.</p><ul><li>When you take on technical liabilities, you incur cash flow penalties in the form of ongoing interest payments, i.e. going slow.</li><li>When you pay down principal on your technical liabilities, you incur cash flow penalties in the form of payments against principal. However, these cash flow penalties are of a different nature: they come in the form of paying down principal in the short term (going slower right now) in exchange for paying less interest (going faster as the principal is paid down).</li><li>The notion of going faster or slower shows the connection between cash flows and time. The cost of ongoing interest payments is an incremental reduction in speed, whereas the cost of payments against principal is an investment of time in exchange for an increase in speed. Restated, there is a trade off between cash flow penalties now (paying the cost of switching) for decreased cash flow penalties in the future (reducing the cost of carry).</li></ul><p>Based on my experience building software, I do not think that the relationship between cash flows, time, and speed is well understood. Much of the problem stems from confusion between the short and long term impact on cash flows that result from making certain tradeoffs. People cut corners under the auspices of short term speed. Often, this corner-cutting actually has the reverse of the intended effect, and can even destroy the chances of delivering. I have seen this thinking lead to the destruction of entire projects within 1 to 2 quarters.</p><p>Almost everyone will agree that a decade is long term and that taking on a lot of technical debt can be a significant risk to longevity. Fewer will agree that a year or more is long term. Very few will agree that a quarter is long term. Nevertheless, the more projects I work on, the shorter my definition of "long term" becomes with respect to technical debt. If you really look at the cash flow trade-offs that result in the relationship between time, speed, and technical debt, and you consider the compounding effect of negative cash flows that result from the debt, it becomes much less attractive to mindlessly acquire technical debt in the name of speed. It often results in going slower, even across the time horizon of a quarter or less. </p><p>So now we have some crude numbers, and we understand how to think about cash flow trade-offs. In part II, we'll present how we formulate and execute a plan to increase technical equity.</p><br /><hr /><br /><p><strong>About Brad Cross:</strong> Brad is a programmer. </p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-71412301778931223192009-03-10T22:24:00.000-07:002009-06-04T22:27:08.355-07:00Kehoe - Smug Post-Modernisms and Other Notions We Get Wrong<p>By John Kehoe - <em>10 March 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s1600-h/kehoe.jpg"><img id="BLOGGER_PHOTO_ID_5343652952609688434" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s200/kehoe.jpg" border="0" /></a> <p>I was watching <a href="http://www.imdb.com/title/tt0099700/">Gremlins 2 </a>with my daughter this weekend (yes, I’m a bad dad, but don’t hold the sequel against me, just the fictional violence). What strikes me about the movie is how cheesy it is. Not the plot but the technology. The video conferencing system, the voice based building controls. I particularly like the talking fire alarm system giving a history of fire, but I digress. It is a great period piece for late 80’s business and technology (Did you know that you could smoke in an office in 1990?). Yes, post modern sophistication relegated to a period piece. Such is father time.</p><p>It got me thinking in a broader context. What are we getting wrong today that will be revealed with the passage of time? We can look at the history of scientific progress. Examples abound in astronomy, biology and physics. The same can be said in social sciences, economics and politics. Up until the 1950's, the universe was thought to be quite small. Up until last year, bundled mortgages looked as a good way to diversify risk. </p><p>How do we know which horse to back? The first place to look is the ecosystem (yeah, sounds touchy feely, but it isn’t) of the technology. <a href="http://www.diamondmm.com/">Diamond </a>created the first MP3 player, a 64MB job. They did this years before <a href="http://www.apple.com/">Apple</a>. Apple won the race, but why? They created a fully contained ecosystem. It consisted of a closed <a href="http://en.wikipedia.org/wiki/Digital_rights_management">DRM </a>format, content, exclusivity of content, blessing of <a href="http://www.riaa.com/">RIAA </a>and a logo program. It didn’t hurt that they hyped the heck out of it. <a href="http://www.microsoft.com/">Microsoft </a>tried the same with <a href="http://www.zune.com/">Zune</a>, but hasn’t had anywhere near the success. Microsoft was too late to the market and didn’t have the best marketing or industrial design (people like polished plastics and nickel alloy). The same is true with the other media players.</p><p>The ecosystem became pivotal. As a consumer, do I go with another ecosystem or do I go with <a href="http://www.apple.com/ipodclassic/">iPod</a>? My best mate abhors all things Apple (except his trusty <a href="http://en.wikipedia.org/wiki/Apple_Newton">Newton</a>) and argues against the iPod. iTunes and iPod are closed DRM systems, the music isn’t portable to other systems, Apple locks in content providers. The arguments are similar to the <a href="http://www.linux.org/">Linux</a>, Apple, Microsoft or [fill in the blank with a comperable technology] proponents or opponents. The fact remains that most people choose the iPod because it has the most mature ecosystem.</p><p>So what if there is no ecosystem? How do I pick the winner? I resort to need and simplicity. What do I need to accomplish? For instance, suppose I have a customer facing application that brings in $100 per minute. When the transaction rate slows, I lose money. I can quantify "normal," define a cost of abnormal activity and prove what additional revenue I can create with further capacity. I can determine my cost for that performance delta. It is a simple model and readily understood. It guides what the impact is, what is my need and what can I afford. It’s a good way to avoid the technology weeds. </p><p>Time makes fools of us all. We can use that to our advantage. If you don’t need technology XYZ, can’t afford it or can’t absorb it, then don’t buy it. The new classic example is <a href="http://en.wikipedia.org/wiki/Blu-ray_Disc">BluRay </a>v. <a href="http://en.wikipedia.org/wiki/HD_DVD">HD-DVD</a>. Both were expensive technologies that consumers would not absorb. The end result of a hard press by <a href="http://www.sony.com/">Sony </a>lead to the capitulation of HD-DVD within a two week period in 2007. This made winners of the people who bought BluRay and the consumers that waited. Don’t mistake the initial BluRay owners as brilliant strategists: HD-DVD could have won as well. At any rate, the first adopters of BluRay paid $900 for bulky players. Better to wait for <a href="http://www.walmart.com/">Wal*Mart </a>to sell them for $99.95. The real winners are the consumers that sat out the battle.</p><p>So we use need and time to our advantage as best we can. We can use a contrarian perspective to the technology cycle. Think of this as the Devil’s Advocate (and yes there is a Devil’s Advocate in the <a href="http://www.vatican.va/">Vatican</a>). This would be considered the "B.S. detector" (a characteristic well honed by Mrs. Kehoe and applied to the auto dealer or to me asking for a 52” big screen). This leads to a skeptical mindset, a healthy maladjustment of the trusting mind. </p><p>Consider the evolution of broadband. Fifteen years ago technologists thought it essential, but prohibitive in cost (think ISDN a.k.a. “I Still Don’t Need”). We knew (or at least strongly suspected) what we could do with broadband communications: distribute information, telecommute (the real reason IT guys pushed broadband), new forms of communication, <a href="http://www.webex.com/">WebEx </a>(which didn’t exist fifteen years ago), shopping, expansion of markets, outsourcing, offshoring, distributive teams, etc. The wheels come off the bus when we start standing up 100 Mbps internet, free municipal Wi-Fi and universal broadband. Why are they needed? Is to keep up with Elbonia? Why should there be a government run Wi-Fi network? If people don’t want broadband why force the build out that capacity? The sixty-four-million-dollar question is: when does a technology become valuable? Fibre to the house was goofy 20 years ago. If you have <a href="http://www22.verizon.com/Residential/Fiosinternet/">ask The Creator why he needs a starship</a>.</p><p>Despite our best efforts, time will still embarrass us (really, the <a href="http://en.wikipedia.org/wiki/Chrysler_K_platform">K car </a>was brilliant idea). What has been the long term impact of <a href="http://en.wikipedia.org/wiki/Michael_Jackson">Michael Jackson</a>? He went from being King of Pop to Regent of Ridicule in short order. Will <a href="http://en.wikipedia.org/wiki/Miley_Cyrus">Miley Cryus </a>be the <a href="http://en.wikipedia.org/wiki/Max_Headroom_(character)">Max Headroom </a>of today? (I do have to claim that my daughter is not a Miley fan, I can’t be that bad of a father.) So foolishness can rule the day, but I doubt that <a href="http://en.wikipedia.org/wiki/Sir_Mix-a-Lot">Sir Mix-A-Lot’s </a>‘<a href="http://en.wikipedia.org/wiki/Baby_Got_Back">Baby Got Back</a>’ will be considered "classical music" in two hundred years. We don’t see the <a href="http://www.sun.com/">Sun Microsystem's</a> ‘We puts the dot in dot com’ commercials (’99-’00) as being seen as the launch pad of corporate success, but an apex of hubris signaling the impending internet bust of ’00. </p><p>Looking at the merits of the solution in the context of its ecosystem, need, simplicity, time and our return models, we minimize our risks and bring a skeptical mindset to the hype cycle. Let's not be the next "dot" in "dot bomb."</p><br /><hr /><br /><strong>About John Kehoe:</strong> John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at <a href="mailto:exoticproblems@gmail.com">exoticproblems@gmail.com</a>.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-58757236675987490382009-02-24T22:20:00.000-08:002009-06-04T22:27:29.677-07:00Pettit - Restructuring IT: Making In-Flight Change<p>By Ross Pettit - <em>24 Febuary 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s1600-h/rjp1.jpg"><img id="BLOGGER_PHOTO_ID_5343624959897658850" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s200/rjp1.jpg" border="0" /></a> <p>All businesses are undergoing unprecedented changes. Revenue forecasts aren’t materializing, capital structures are proving unsustainable, and operations are being scrutinized for inefficiencies. This, in turn, means that businesses are being completely restructured in how they are capitalized, organized, managed and governed. As businesses restructure, so will IT.</p><p>As we face restructure, we have to look critically at our <a href="http://agilemanager.blogspot.com/2007/10/it-governance-maximises-it-returns.html">IT lifestyle</a>. We know that if we eat a poor diet and don’t exercise, we run a greater risk of health problems than if we eat a healthy diet and exercise regularly. The same applies to IT: if our work habits lack discipline, we’re going to have health problems that, in turn, put business operations at risk equivalent to heart disease or diabetes.</p><p>Agile and Lean offer IT a healthy lifestyle choice: disciplined execution of a set of best practices give greater focus, consistency and transparency to operations than we get from traditional approaches to IT. Experience in a variety of business domains tells us that we can expect significant impact by taking on Agile practices: we will reduce the probability of a catastrophic failure, defects will decline substantially, delivery times will accelerate, and the business value of what we deliver will increase. </p><p>But restructuring to be an Agile / Lean IT organization is not something that happens by management fiat. Agile IT requires that each person embrace fundamental principles that value the business problem at hand as opposed to the technical problems we concoct. This requires behavioral changes that run counter to decades of training, messaging and mentoring embedded in the IT profession. In fact, it goes to the heart of the oft-cited gap between business and IT: day-to-day IT activity is often fundamentally misguided, as people are busy solving the wrong problems. Indeed, it is not uncommon for people in IT to subserviate a very real business need to go in pursuit of speculative technological “future-proofing.” </p><p>Given the urgent need to restructure, this behavioural gap presents IT leaders with a significant challenge.</p><p>First, restructuring takes a lot of effort. If restructuring IT requires changes to fundamental work habits, we must not underestimate the amount of effort that will be needed to bring this change about. Bridging the gap between “how we work today” and “the results we must achieve given the reality we face” is not simply an exercise in tools and training. It requires a concerted effort to change the behaviours that underlie how work is done: how requirements are defined, solutions are developed, teams are organized and managed and IT is governed. This comes about through experience. Change happens within each team and department as people gain proficiency with new work habits while delivering, supporting, and maintaining solutions.</p><p>Second, IT can't shut-down while it restructures; it must be restructured while delivery work is in full flight. That means the restructuring effort itself will be subjected to change and adaptation. This makes restructuring a moving target, which both blurs the vision of the target state and wears down people’s patience and energy for the change. </p><p>Significant organizational effort spent in pursuit of a moving target will put the change leader in a constant state of conflict. On the one hand, he or she risks managing to a compromise, where long-term sustainability is sacrificed for short-term "results" (often, ironically, in the name of pragmatism). For example, a project team may elect not to introduce unit testing because the effort is believed to be too great and the business need too urgent. The team may write code faster initially, but it will prove to be a false efficiency as defects rise and time spent refactoring obliterate any gains. On the other hand, the change leader must not be dogmatic. An IT organization doesn’t exist so that it can be Lean, it exists so it can deliver business results. Too great of emphasis on process – insisting on 100% unit test coverage, for example, just for sake of having high unit test coverage – risks prioritizing process in favor of results.</p><p>Most of the challenges the change leader will face during in-flight restructuring come down to a simple, if not always obvious, test: are we <em>reconciling the reorganization to the business demands</em> or <em>reconciling the reorganization to old work habits?</em> The prior part of the test helps us be sure that dogma doesn’t trump results. The latter tells us that we must not compromise in the name of making everybody happy.</p><p>To make this decision consistently, even when the goalposts are moving, change leaders must have a clear understanding of both the business need and the goals of the restructuring. By keeping the business outcomes such as reduction of defects or accelerated time to delivery the clear priority, we bring unambiguous focus to the change effort. And that focus is critical. Every day, change will be challenged by all kinds of things: distracting and counter-productive technical objectives (e.g., “we need to solve every possible problem we may have in this and any future application that requires session management”), irrelevant, non-value-added IT practices (e.g., "we've always required effort-remaining project status reports"), and individual motivations that run counter to change (such as job preservation or people's "stationary inertia" at work). In-flight operations restructuring requires intense, unrelenting effort to swim against the tide of “how things have always been done here.” The change leader must have a clear vision for operations that is flexible to business demand but uncompromising to IT convenience if there is to be a real, durable restructuring.</p><p>The change leader must always be clear that the goal of restructuring is to have the organization executing in such a way that it sustainably yields better performance. To be sustainable, we don't just need solutions to report improved technical measures, we need to work in such a way that day-to-day project decisions do no harm, much like decisions we take in our personal lifestyles. For example, we can send code to the "technical clinic" for IT liposuction, where we invest time into remediating tight coupling, dependencies and complexity so that a team has a clean code base, free of technical debt. However, just as the stomach-stapled person may resume bad dietary habits and regain weight, so will the IT team with the remediated code base resume bad habits. This means that IT leaders must insist on a constant, independent validation that restructuring has taken root. One way to do this is to regularly scorecard team performance to scrutinize execution. Another is to make sure that organizational structures – incentives and rewards, recruiting and promotion, governance and oversight – reinforce the Agile value system. If these things are done, old habits are unlikely to return.</p><p>The pressure has never been greater on IT. Business is asking, “what are you doing for me this quarter” with increasing anticipation and scrutiny. The best guarantee that IT operations can adequately and professionally answer this question is to execute in a transparent, consistent and disciplined manner. In an uncertain business world, that’s the best form of “futureproofing” IT can pursue.</p><br /><hr /><br /><strong>About Ross Pettit:</strong> Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active <a href="http://agilemanager.blogspot.com/"><strong><span style="font-family:Tahoma;font-size:85%;color:#800080;">blogger</span></strong></a> on topics of IT management, governance and innovation. He is also the editor of <a href="http://alphaitjournal.com/">alphaITjournal.com</a>.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-74061912282738490962009-02-11T22:14:00.000-08:002009-06-04T22:19:41.185-07:00Reiser - Getting the Most out of Offshore Development<p>By Greg Reiser <em>11 February 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP2EfeQunSBsF8fotS-75M0ZxxzMlgp_bdlIdPu0oCnDndoc0oxx5jZIeGxqq2s9-zaRp7HlRhttcfoo32DG0ycxGdIfsYT9s9dg9cvj2ltQIcmjUy1_YSg0OY0YR4ocSAwCWh8DT-wM4/s1600-h/GReiser.JPG"><img id="BLOGGER_PHOTO_ID_5343708762667349154" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP2EfeQunSBsF8fotS-75M0ZxxzMlgp_bdlIdPu0oCnDndoc0oxx5jZIeGxqq2s9-zaRp7HlRhttcfoo32DG0ycxGdIfsYT9s9dg9cvj2ltQIcmjUy1_YSg0OY0YR4ocSAwCWh8DT-wM4/s200/GReiser.JPG" border="0" /></a> Many businesses avoid using offshore resources to implement high-value, high complexity software projects and many who try are frequently dissatisfied. In a recent survey <a href="http://www.forrester.com/">Forrester Consulting </a>found that nearly half (46%) of businesses were unhappy with their offshore provider for development of mission-critical applications. <p>This begs the question, “Is offshore development incompatible with high-value high-complexity projects?”</p><p>My experience suggests otherwise. I have worked with many talented teams that have successfully delivered high-value high-complexity solutions using a distributed development model that takes advantage of talent located in multiple locations around the world.</p><p>In this article I will briefly describe how specific practices, some associated with agile development, will help you get maximum value out of your distributed development efforts.</p><p>(Please note that I prefer to use the term “distributed development” instead of “offshore development”. This describes projects where work occurs in multiple locations. It is my experience that there are no “offshore” projects. Rather, there are distributed projects where a good bit of the work is performed offshore.)</p><p><strong>Involve the whole team in the planning</strong> – This is counter-intuitive to those organizations that rely on up-front analysis and planning and then engage a development team (possibly a vendor) for the implementation work. This presents two problems.</p><p>First, the development team will insist on doing its own analysis in order to fully understand the business requirements document, use cases, RFP, etc. Hence, some of your up-front effort will be redundant.</p><p>Second, and more importantly, it’s during the up-front analysis and planning that the business sponsors and subject-matter-experts establish a shared understanding of the project vision, business objectives and priorities. If the development team (or vendor) is not involved in this process they will be less effective in adapting when the inevitable surprises occur.</p><p>Sorry folks, documentation just doesn’t cut it. To paraphrase General <a href="http://en.wikipedia.org/wiki/Dwight_D._Eisenhower">Dwight D. Eisenhower</a>, “The plan is nothing, but planning is everything.”</p><p><strong>Monitor the product, not the process</strong> – Many agilists criticize <a href="http://en.wikipedia.org/wiki/Earned_value_management">earned value analysis </a>(“EVA”). Although the EVA technique has shortcomings, the basic idea of assessing project progress by the value delivered is sound. It is much better to assess progress based on functionality delivered rather than interim deliverables such as the System Design Specification (“SDS”) or worse, budget or schedule consumed.</p><p>Whether the project team is distributed or not, in-flight metrics based on implemented functionality and user feedback are significantly more reliable barometers than traditional “percent complete” metrics. How many projects have you seen that are 90% complete for half their actual schedule?</p><p>Although the SDS may be a very important and valuable artifact (I’m not one of those people who demonize all documentation), its veracity is suspect until an implementation validates it.</p><p><strong>Admit that you have a (communication) problem</strong> – It doesn’t matter if your project methodology is agile, waterfall or something else. Communication and efficiency suffer when team members are separated by miles. It gets worse when they are separated by time zones as well. In addition to the obvious investments in communications infrastructure and practices (high-quality speakerphones, high-bandwidth networks, overlapping workday schedules, etc.), consider some not so obvious practices.</p><p>One of my favorites is the “exchange program”. Have people from each work location spend time working (not just visiting) in the other work location. I’m talking about at least two weeks at a time, working side by side with peers in the other geography. This is both an effective knowledge-sharing and team-building technique.</p><p>Don’t give in to the argument that “money saved on travel can be more effectively applied to real work”. The improvements in efficiency far outweigh the additional travel costs. On one large complex program we experienced a 200% increase in throughput after we implemented an exchange program.</p><p>I don’t necessarily advocate expensive video-conferencing equipment and services. Although it is a blessing to have access to such, the cost-benefit is not as favorable as it is for less technically sexy investments.</p><p>The bottom line is that your project plan must address the communication challenges inherent in distribution. If the necessary investments exceed the benefits of doing the project in a distributed way then don’t do it that way.</p><p><strong>Redundant roles</strong> – A typical pattern for distributed projects is to have the project manager, subject-matter-experts (“SME”) and business analysts at the customer site and the developers and testers at an offshore facility. This works quite well for small, short-term projects, but it is sub-optimal for large, complex programs.</p><p>Concentration of expertise and/or decision-making in one location slows the project down, as the development team often has to wait a full day (best case) when certain types of impediments arise.</p><p>Having business analysts and/or SMEs close to the developers and testers improves throughput as questions are answered much more quickly. Having project managers in each location improves throughput as many decisions can be made much more quickly. Having developers at the client site improves throughput as critical defects can be resolved immediately and integration challenges can be addressed in a timely manner.</p><p>From a lean perspective, redundant roles are actually a best practice because the apparent waste in redundant roles is significantly less than the waste generated by the wait times in the more typical staffing model.</p><p><strong>Monitor technical integrity</strong> – “<a href="http://alphaitjournal.blogspot.com/2008/08/cross-technical-liabilities-malignant.html">Technical debt</a>” is a metaphor developed by <a href="http://en.wikipedia.org/wiki/Ward_Cunningham">Ward Cunningham </a>that describes the long-term terms costs associated with “quick and dirty” development. The “interest” on this debt is realized in the form of increasing development costs due to inflexible and/or overly complex design, excess dependencies, duplication, defects, etc.</p><p>Technical debt management is important for any project. Distributed development makes technical debt management more difficult because some, if not most of the code is developed by the offshore part of the team. Hence there is a greater risk that by the time the symptoms of too much technical debt become obvious, the cost to correct will be high.</p><p>You might replace your offshore team due to poor performance and you might even recover some of your costs. But if this really is a mission-critical project, your business will still suffer. Although you can and should apply manual techniques for monitoring the technical integrity of the software under construction, I have found that the use of automated tools to monitor indicators such as automated test coverage, adherence to coding standards, design quality and design complexity can serve as early warning signals for technical debt growth.</p><p>Using these types of tools within an automated build process that sounds an alarm when metrics fall outside specified thresholds accomplishes two things. One, they trigger investigation and potential remediation when it is still possible to do so at low cost. Two, they automatically encourage design discipline. No one wants to be singled out for violating coding standards, for not following the agreed upon testing discipline, or writing unnecessarily complex code.</p><p>Once again, a modest investment can reduce risk and saves significant costs within a relatively short period of time.</p><p>These are but a few techniques, some obvious and some not so obvious, that help make it possible to execute high-value high-complexity projects and programs via a distributed model. Look for future articles for more practical learnings from the trenches.</p><br /><hr /><br /><strong>About Greg Reiser:</strong> Greg is a software development professional with 20+ years of experience as a developer, project manager and a consultant. He has experience in a wide range of industries including banking, insurance, publishing, logistics, healthcare and telecommunications. Greg has helped numerous enterprises deliver mission-critical solutions using advanced software development practices. He is currently focused on helping organizations get the most out of global development capabilities.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com6tag:blogger.com,1999:blog-123318888665066571.post-1568491088286942462009-02-04T22:01:00.000-08:002009-06-04T22:03:56.391-07:00Ververs - IT's Leadership Opportunity<p>By Carl Ververs - <em>4 February 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglQET-x95oDd83mia_XJAp6a2hAyZjnZ-jLpxSEKI-uMTRVCuEaA1a7g3FJwDnzXIXxKVn-G1Qf1Lg5apO5WtV41ylOKMPQ5D8TrUm6umXSSlUoirbzsaI5qKAGuy-wHVD59e-Bp2UDEY/s1600-h/ververs.jpg"><img id="BLOGGER_PHOTO_ID_5343639697043836450" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglQET-x95oDd83mia_XJAp6a2hAyZjnZ-jLpxSEKI-uMTRVCuEaA1a7g3FJwDnzXIXxKVn-G1Qf1Lg5apO5WtV41ylOKMPQ5D8TrUm6umXSSlUoirbzsaI5qKAGuy-wHVD59e-Bp2UDEY/s200/ververs.jpg" border="0" /></a> <p>In his latest alphaIT article, <a href="http://alphaitjournal.blogspot.com/2009/06/pettit-come-hour-come-leaders.html">Ross Pettit</a> writes about how true leadership is urgently needed in IT, now that business restructuring is becoming a means of survival for many companies.</p><p>An August 2008 <a href="http://ubmtechnology.mediaroom.com/index.php?s=43&item=2087">study</a> by InformationWeek revealed that executives outside of IT value leadership more than any other characteristic in CIOs. Having experience running a business unit outside of IT is considered very valuable as well. These two factors combined leave no room for interpretation: IT needs to stop thinking that just “managing the shop” suffices and realize that providing true leadership is critical if it has any aspirations of retaining relevance.</p><p>I posit that in many cases IT has been lacking true leadership for a very long time. For some strange reason, people who do one thing very well rise to the top of management ranks: somebody who was the first technologist in a firm, somebody who ran a certain project well, somebody who has technical knowledge and skills that were pertinent at some point. What is neglected is the individual’s ability to lead, adapt to changing business contexts and inspire others to do the same. It is assumed that success in one context – as a manager or developer in a specific project team – automatically translates into success in another.</p><p>It is hard to resist promoting people who are like us and who work like us, but in so doing we create a self-sustaining pattern of like traits to be promoted, warts and all. In evolution, this is a guaranteed path to extinction. Weak leaders promote other weak leaders. We may be surrounded by competent technologist or technology managers but we’ve shut out true leaders who have the courage and determination to not just shake the apple cart, but make something other than apple pie. Arguably, the people we need the most – the innovators – are completely blocked out.</p><p>The Financial Times recently ran an <a href="http://www.ft.com/cms/s/2/d65cc760-e35a-11dd-a5cf-0000779fd2ac.html">article</a> about the animators at Disney. After Walt died, the remaining veterans who had worked directly with him, the so-called “nine old men” were promoted to run the studio. They were not exactly top-shelf animators, and it showed. The outstanding talent Disney had attracted over the years – among others an obscure guy named <a href="http://en.wikipedia.org/wiki/Tim_Burton">Tim Burton</a> – walked out within a few years because they were managed badly.</p><p>In his blog, <a href="http://www.informationweek.com/blog/main/archives/2008/04/the_new_cio_hir.html">John Soat</a> touches on the topic of hiring IT executives and quite a few people comment how it is only fair to promote from within. Luckily, several commentators have a level head and state that firm should hire and promote people who can effectively bring change.</p><p>Here is how this cycle can be broken. IT managers very often have a contentious relationship with the business. The business should seek out people who are not in senior management roles but who are very vocal and active in the company’s technology. Invite these individuals to partner with the business on pursuing the action items Pettit lists in aforementioned article and watch what unfolds.</p><p>To illustrate how effective this can be, let’s examine the case of a Chicago options trading firm. The business side was very unhappy with the technology leadership but could not find a way to improve on that. They hired a CIO who talked a good game, but did not have the mettle to change anything, either by motivation, coercion or force. Then the traders partnered with a few “vigilante technologists” who had been actively chipping away at the established IT order by introducing new technologies and innovative solutions and funded an innovation group. In short order, this group started to produce real revenue-generating solutions, introduced new ways of working and quickly overshadowed IT management in providing true leadership. Those who tried to interfere with this group’s progress were swiftly isolated and rendered harmless. This set the precedent that business-as-usual was over and IT as a whole was going to be held to a new, higher standard.</p><p>Yes, change is scary, especially if that change violates our core beliefs and assumptions. But with the current economic situation, companies don’t have a choice but to take decisive action. As Pettit’s, and <a href="http://agilemanager.blogspot.com/2009/01/come-hour-come-leaders.html">related articles</a> state, now is the time for companies to shake their IT department's apple cart a good bit, and shake the rotten apples out while they’re at it.</p><p>It’s hot in the kitchen. Time for the faint of heart to stand back.</p><br /><hr><br /><p><strong>About Carl Ververs</strong>: Carl has been a business transformer through technology since the start of his career two decades ago. Always at the vanguard of new thinking and creative application of systems, he built CRM systems, used SOA and applied Agile techniques well before they were named.</p><p>Carl's technical expertise lies mainly in high-performance computing for derivatives trading and business process management. His background spans a wide spectrum, including business application specialist, hierarchical storage system architect, customer management systems designer, trading operations manager, Agile project Management coach, SOA practice lead, PMO/QA director and deputy CIO. Carl is an avid musician and composer, computer graphics artist and geopolitical pundit. He lives in Chicago with his wife and son.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com2tag:blogger.com,1999:blog-123318888665066571.post-35760630828896375532009-01-28T21:55:00.000-08:002009-06-04T22:00:35.625-07:00Kehoe - A DEC VMS Cluster, a Funky Chair and a Toaster Oven Walk Into a Bar...<p>By John Kehoe - <em>28 January 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s1600-h/kehoe.jpg"><img id="BLOGGER_PHOTO_ID_5343652952609688434" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s200/kehoe.jpg" border="0" /></a> <p>I do not like change forced by ‘the Man’, change out of my control or change that doesn’t help. I do like change that I push, change that makes my life easy and change that puts money in my pocket. As IT professionals, we push change. We often do so without appreciating what our users require, what the users are doing or the historical context of our solutions.</p><p>What are we doing wrong? Let’s look at a manufacturing example. I once owned a nice little under-the-cabinet toaster oven, circa 1991, that worked reliably for almost two decades. When it hiccupped I simply fixed it. Alas, it eventually started belching smoke and so I replaced it. </p><p>In the IT world, this belching represents the old, unsupported application that we are afraid to touch, lest it combust. It has exceeded its <a href="http://alphaitjournal.blogspot.com/2008/12/cross-cost-of-carry-versus-cost-of.html">carrying cost</a> and the time has come to replace it. My quest to find a new toaster oven took a while as the new models had been redesigned to meet current codes (think the manufacturing equivalent of SOX, HIPAA and whatever the politicians are about to do to the financial sector). My <a href="http://en.wikipedia.org/wiki/Elbonia">Elbonian</a> made Char-Nobyl 8000 toaster oven, finally arrived (long past due, as often happens in software system replacement). We had to measure and mount the heat shield as well as mate the oven to the mount (application infrastructure). The instructions turned out to be wrong. I could not reuse the existing mounting equipment. Matching up the supplied components was problematic. Poor design, poor build, poor execution and dodgy installer.</p><p>Now we get to use the oven. My first thought: why is my toaster oven plastered with English, Spanish and French instruction and warnings? I bought it in Chicago, not Paris or Buenos Aires. This is the small electronics world equivalent to the user interface. It’s annoying (sure I’m ethnocentric, but a Frenchman and Argentinian would say the same: they didn’t buy a toaster in Chicago). </p><p>Now I want to toast a bagel. Simple task: insert bagel; set darkness; start the job; repeat as desired (or ‘insérer bagel; set obscurité; démarrer le poste de répétition comme souhaité’). It’s not that simple with this toaster oven. This baby comes with a plethora of dials. First you set the darkness level. Then you rotate a knob clockwise, then counterclockwise. The third step is to wait for the light to turn green (which, for some reason, turns blue instead). Finally I push the button to ‘launch my bagel into orbit’. Success! I toast another and it’s burnt. Turns out I need to recalibrate my darkness level with each toasting to avoid burning. At least it doesn’t belch smoke.</p><p>This is a good metaphor for the weakness of IT applications: we toss in every conceivable feature, the UI is unnatural, the instructions are off, the business rules are mercurial… you get the idea. </p><p>How do we make a better toaster oven? Consider the past and the trade-offs. Do we need to replace the heat shield and mounting locations? Can we at least use the same bolt layout? Do we need the languages? Do I need this degree of globalization? What about the UI, why have the extra dial? Why can’t the oven maintain a regulated temperature? In IT we tend to design what we think we need, not what our customer needs. </p><p>Asking the customer is no guarantee of success. We’re still likely to end up with dozens of ideas, many of them contradictory or just plain bad. A few gems may exist among amongst the cruft, but they are sometimes difficult to distinguish. We may even avoid considering customers or users who have a propensity to complain. </p><p>So where does that leave us? We must look to the past. Just because an idea is old doesn’t mean it’s stale. Consider this story in the context of today’s web 2.0. In the late nineties, I worked with Digital Equipment Corp (DEC) systems. I once chatted up a DEC field SE about the reliability of their hardware. He proudly told the story of a 911 emergency system that had been running on a VMS (a real operating system) cluster (DEC invented the technology) for 16 years with zero downtime. The design was thoughtfully centered on what the user required and what the technologist could do. Yes, they periodically refreshed the software and the operating system. All this was done without bringing the application down. Try that with today’s technology mix and applications. Would you want a 911 system running on a cloud or web 2.0? </p><p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIOPuz_Lfy5pMr9nP-cSYAt9XdgjIp3B8lR5JuUqusQE74Uc9ZMpgRWjWK_hyNE9gywxiq_gCzn9jBSSsqBLPiVwKl11bSli8DWYeijmMlQ5ICSaC3MUu7ITxZfRXDpKdiw_StHvr4sHk/s1600-h/chair.JPG"><img id="BLOGGER_PHOTO_ID_5343703168805397490" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 142px; CURSOR: hand; HEIGHT: 196px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIOPuz_Lfy5pMr9nP-cSYAt9XdgjIp3B8lR5JuUqusQE74Uc9ZMpgRWjWK_hyNE9gywxiq_gCzn9jBSSsqBLPiVwKl11bSli8DWYeijmMlQ5ICSaC3MUu7ITxZfRXDpKdiw_StHvr4sHk/s320/chair.JPG" border="0" /></a>Here’s another example. Remember the really cool chairs in the 1960’s sci-fi movies. In all our sophistication, we mocked the strange designs. Surely they had to joke (OK, they were being serious, but the design did not age well) that anyone would use such a contrivance. Well forty years later, I’m at a state of the art (opened three days earlier) corporate video conference center for a $34b company. What’s the first thing I noticed, after the three HD armed cameramen and thirty foot projector setup that put IMAX to shame? I see these wild-looking chairs that could have come from <a href="http://www.imdb.com/title/tt0062622/">2001: A Space Odyssey</a> or <a href="http://www.imdb.com/title/tt0074812/">Logan’s Run</a>. </p><p>So what can we glean from my tales? First, the problems we see today have analogues in the past. A lack of historical perspective in our current crop of technologists hampers good problem solving (Action item: crack open a VMS manual to steal some ideas). Two, our solutions are too often divorced from the use case. Our users are not forthcoming in what they want nor do they fully appreciate what they need. We must crawl into their heads to understand what is required and build from those use cases. I say use cases deliberately: we don’t need pretty interface ideas. We do need to value the UI, but we can't simply put out something shiny and think that's the end of it. Form must follow function, which means we must first understand the function. We need to know how they do their jobs today and how the tool we are building will help them do it. Three, we are making software that is too difficult to use. Consider the toaster oven. Why the abrupt disconnect from the past? If your users are coming from 3270 terminal land or fat client world, our objective is to make lives easier with technology, not to simply require users to change from one technology to another. Finally, consider the plumbing. Are we proposing a more reliable solution than the customer has or are we opening ourselves to reliability and performance grief? </p><p>So crack open those old manuals, play with some assembly code and enjoy some classic sci-fi movies this weekend. On Monday you can start looking at use cases. By Friday you might be able to deliver some ‘change’ that doesn’t ‘look’ like change and make change resistant users think they came up with it. </p><br /><hr /><br />About John Kehoe: John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at <a href="mailto:exoticproblems@gmail.com">exoticproblems@gmail.com</a>.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com1tag:blogger.com,1999:blog-123318888665066571.post-34726687393567989582009-01-21T21:51:00.000-08:002009-06-04T21:59:33.158-07:00Pettit - Come the Hour, Come the Leaders<p>By Ross Pettit - <em>21 January 2009</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s1600-h/rjp1.jpg"><img id="BLOGGER_PHOTO_ID_5343624959897658850" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s200/rjp1.jpg" border="0" /></a> It’s pretty obvious by now that we’re not in an ordinary downturn. The US Federal Reserve and the Bank of England have invested well over $1 trillion propping up their respective financial services sectors, and every indication is that there is more yet to be spent on asset purchases and guarantees. For all intents and purposes, the domestic US auto industry has failed (with, as of this writing, the notable exception of Ford Motor). The Baltic Dry index has fallen 96% from its peak and there are indications that <a href="http://www.telegraph.co.uk/finance/4229198/Shipping-rates-hit-zero-as-trade-sinks.html">global container shipping is effectively free</a>. Deflationary forces – with which few of us have any first hand experience – are evident in everything including volumes, prices, salaries, staffing levels and asset values. Add to the landscape completely unexpected large-scale incidents of fraud such as Satyam and Madoff and there is no denying that we live in very challenging times, with few precedents or patterns. <p>The headlines today are dominated by bailouts. Before long, they’ll be about bankruptcies. This will create a new business landscape, the shape of which none of us can fully predict. One thing we do know is that before the dust settles, businesses both healthy and unhealthy will have to go about the task of restructuring.</p><p>Restructuring will extend to IT. IT can keep pace and perhaps even get slightly ahead of the trend. But that requires leadership, and leaders are in short supply in all areas of business. This is obvious from the predominance of two common attitudes: complacency and elective ignorance. </p><p>First is complacency, often bordering on denial. There are quite a few people taking a “wait and see” attitude, believing that the economic situation isn’t as bad as is being reported (lots of business is still being transacted), governments are stepping in (weren’t we taught in history class there could never be another “great depression?”), there’s been a change in US leadership, and so forth. The prevailing attitude in this camp is that the economy will work itself out and that businesses are not at wholesale risk. </p><p>There are also a fair few willing to ignore what's happening, electing to focus exclusively on execution. Since none of us control the economy, the thinking goes, better that we just get on with the things we do control, such as day-to-day execution. We need to <a href="http://bradfordcross.blogspot.com/2009/01/no-nonsense-is-nonsense.html">step up</a> our efforts and fight the good fight. Times will be tough, but putting our nose to the grindstone will see us through. Cut costs. Sacrifice. Be positive and optimistic. </p><p>In the current economic context, both of these attitudes are acts of capitulation. They substitute “hope” and “aggressiveness” for genuine leadership.</p><p>As leaders of IT organizations, we’re several steps removed from the line-of-business of our partners, making it difficult for us to be true business leaders. It also places us in a vulnerable situation: if IT is perceived as a <a href="http://agilemanager.blogspot.com/2007/06/strategic-it-does-more-than-assume.html">utility</a> (and not a strategic partner) we’re seen as a draw on revenues rather than a core competency in long-term success. The CEO and the board won’t look to us for strategic contribution as much as they’ll look for a budget request consistent with the deflationary times.</p><p>This is a frustrating environment in which to try to lead as traditional market and operational moves are acts of blind faith or wild ambition. What we can do today to provide leadership for our business partners and our teams? </p><ul><li>Have a firm but malleable <strong>business vision</strong> founded in facts. </li><li>Pick a <strong>timeframe</strong> that can be monitored and adjusted. </li><li><strong>Restructure</strong> operations for responsiveness.</li></ul><p>Here are six practical things we can do to execute a leadership agenda.</p><ol><li>Vision: <em>We must forecast a bottom for our business / industry.</em> Relax: any forecast we make is going to be wrong. The point isn’t to be precicely accurate, but to define a floor against which we can reconcile and explain all of the business decisions we will face in the coming months. That floor must be something we arrive at independently, by analyzing the data (macro and micro) at our disposal. It is important that we process every bit of economic data and filter signal from noise, fact from emotion. We cannot selectively pick facts nor emotionally align with an outcome that we would like to be true. If we preface any replay of our analysis with “I believe..." we have failed this test. </li><li>Timeframe: <em>We must choose the indicators that we’ll use to monitor and adjust the timing (and the details!) of our forecast.</em> Not only is it important that we forecast a bottom, we must get our fignernails dirty with the data. This will allow us to ascertain whether reality is evolving toward or away from our predicted future state, and give a reasonable time horizon to adjust our execution. To do this, we need data. Headliners such as the S&P 500 and FTSE 500 are interesting, but can bake in stale data such as last quarter’s sales or dividend forecast. Look to leading indicators of economic activity. For example, if we’re heavily exposed to consumer spending, we can look to the <a href="http://en.wikipedia.org/wiki/Baltic_Dry_Index">Baltic Dry index</a> to see when global trade starts to show sustainable signs of life. Or if we're close to construction or financial services, we can look to see when the <a href="http://www2.standardandpoors.com/portal/site/sp/en/us/page.topic/indices_csmahp/0,0,0,0,0,0,0,0,0,1,1,0,0,0,0,0.html">Case-Shiller index </a>shows that house values are again consistent with rates of income growth as they were prior to 2003. Better yet, we can create our own composite index out of key indicators specific to our situation, such as the enterprise value or the percentage of toxic-to-tangible assets of our customers. </li><li>Vision: <em>We must be specific and direct with everybody – from the board, to the CEO and CFO, to our business peers, to everybody in our teams – about what the data is telling us.</em> Does it appear that our business is shaping up to be a predator, a buyout target, or in a different business entirely? Figure out the business needs that IT must satisfy to support the company that will emerge on the other side, and make sure we are in full agreement with our busienss partners. We must articulate a decoupled vision so that we can explain and focus efforts on the right problem at the right time. We can encourage people to take the initiative in acquiring new skills in alignment with that vision. The data may be negative and it may not make people very happy, but how we act and prepare, and how we explain our actions and preparations, inspires confidence more than all the rah-rah optimism in the world will ever achieve. </li><li>Restructuring: <em>We must change the way we work to maximise responsiveness.</em> We cannot predict when recovery will happen or what form that recovery will take. Cutting costs to withstand a downturn in the hope that recovery is around the corner (and with it a return to business as usual) is not leadership. Being sustainably responsive to whatever the economy, the market, governments and the competition deals us is leadership. We can act very boldly to eliminate <a href="http://agilemanager.blogspot.com/2008/03/margin-call-on-leveraged-time.html">situational complexity</a>, <a href="http://agilemanager.blogspot.com/2008/12/agile-pmo-gatekeepers.html">unaligned gatekeepers</a>, and any other obstacles that make it difficult to <em>get things done</em>. We can also look very closely at <a href="http://www.richarddurnall.com/?p=44">Lean principles</a> to not only eliminate waste but to make sure effort is directed toward results. </li><li>Restructuring: <em>We must take a long, hard look at the portfolio for any self-targeted missiles.</em> The one thing that will undermine our leadership in the eyes of our business partners is if we are blindsided by something that is in our control. Especially in difficult times, people will do things to contain bad news in the fear of losing their jobs, so we must be vigilent: do we have any projects that could surprise us with a <a href="http://agilemanager.blogspot.com/2008/11/pmo-divide.html">spectacular collapse</a>? Is Bernie Madoff one of our project managers (or worse, our project portfolio manager?) We need to find out now. Right now. We can do this by bringing <a href="http://agilemanager.blogspot.com/2009/01/agile-pmo-results-based-execution.html">unrestricted transparency</a> to our projects. </li><li>Restructuring: <em>We must identify</em> <em>the top 3 capabilities that will be the most valuable in our future and patiently pursue them.</em> Perhaps our organization has a deficiency in project management, or we envison changing from a custom appdev shop into an integration shop. We can take some long but lightweight positions in these different capabilities. For one thing, we can look internally and identify the people in whom we want to invest for skill development. We can look externally as well: labor supply outweighs demand, so this is an opportune time to advertise for new hires. We can also partner for capability: plenty of firms are coming to grips with the same set of challenges, so there's no need to go it alone. Above all else, we must take our time and make sure we get the right people under the right circumstances. And we mustn't assume that we'll recognize the right people or the right circumstnace especially if we've no experience or a poor track record of acquiring it. We must invest in developing interviewing techniques, and be aggressive but fair in defining terms and opportunities for partners.</li></ol><p>This isn't easy to execute. A lot of people in IT lack business fundamentals and may struggle to understand our goals and objectives. We will make mistakes and suffer setbacks. And it can be difficult to explain to people engaged in daily firefighting why this demands attention. But going off in a fit of blind execution is economic "trench warfare," a tactic that has a history of unpleasant consequences. Survival may be at the front of our minds, but as leaders we must be able to articulate a future that is more than just survival. Many IT organizations "survived" the downturn of 2001-3 but never fully "recovered," underperforming for their business partners in the years that followed. We can't ignore threats to survival, but we must restructure and reorganize with informed preparedness, leading toward some vision - even if a bit inconclusive on the details just yet - of a transformed destination. To realize that vision, we're going to need every oar in the water, so it is best that we treat our people with respect and give them full disclosure of our vision and expectation, and the opportunity to take the initiative in sharing in its fulfillment.</p><p>At a time when a lot of businesses are on fire, this sounds like a lot of etherial work. And there is no denying that we’re in for a lot of long days and long nights, sacrifices and hard decisions just to stay on top of operations. But this isn’t the time to be tactical. Playing the hand we're dealt and hoping for the best, or simply executing pell-mell in the expectation that something good will come of it, abdicates leadership at the time it is needed the most. Businesses don’t need administrators doubling down on the same techniques, they need leaders ready to invent and innovate in a different and as of yet unknown commercial landscape. Making the effort to shape our situation relative to an informed, forward-looking business context will give us that much more of an opportunity to determine our futures.</p><br /><hr /><br /><strong>About Ross Pettit:</strong> Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active <a href="http://agilemanager.blogspot.com/"><strong><span style="font-family:Tahoma;font-size:85%;color:#800080;">blogger</span></strong></a> on topics of IT management, governance and innovation. He is also the editor of <a href="http://www.alphaitjournal.com/categories/20080616"><strong>alphaITjournal.com</strong></a>.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com1tag:blogger.com,1999:blog-123318888665066571.post-76963663875671389352008-12-04T21:39:00.000-08:002009-06-04T21:47:10.516-07:00Cross - Cost of Carry versus Cost of Switching<p>By Brad Cross - 4<em> December 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s1600-h/bcross3.JPG"><img id="BLOGGER_PHOTO_ID_5343646599935290498" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s200/bcross3.JPG" border="0" /></a>In the technical balance sheet, the cost of carry and cost of switching are proxies for cash flow. <p>When you take on technical liabilities, you incur cash flow penalties in the form of ongoing interest payments, i.e. going slow.</p><p>When you pay down principal on your technical liabilities, you incur cash flow penalties in the form of payments against principal. However, these cash flow penalties are of a different nature: they come in the form of paying down principal in the short term (going slower right now) in exchange for paying less interest (going faster as the principal is paid down).</p><p>The notion of going faster or slower shows the connection between cash flows and time. The cost of ongoing interest payments is an incremental reduction in speed, whereas the cost of payments against principal is an investment of time in exchange for an increase in speed. Restated, there is a trade off between cash flow penalties now (paying the <em>cost of switching</em>) for decreased cash flow penalties in the future (reducing the <em>cost of carry</em>).</p><p>Before we look further at these terms, we need to first introduce another concept: volatility. <em>Volatility</em> is the extent of change of a component, including maintenance and new development. The more work there is to do in an area of the code that has high technical liability, the greater the cost to complete that work. You can determine the volatility of a component by looking at previous project trackers, defects logs, the raw size of the component, source control history, and backlog work items.</p><p><a href="http://en.wikipedia.org/wiki/Cost_of_carry">Cost of carry</a> is the sustained cost of servicing your liabilities. It represents the decrease in speed and corresponding increase in time that it takes for developers to complete tasks due to technical debt. Volatility is a major component of cost of carry: the liabilities in a high volatility component are the liabilities with the highest cost of carry across your application.</p><p>Within a component, your cost of carry is the time spent on production issues, maintenence issues, adding new code to change or extend the system, as well as testing and debugging time. The cost of carry for an indebted component also includes costs from its effects on dependent components. In other words, some dependent components are more difficult to productionize, maintain, change, extend, test and debug becasue of their dependency on an indebted component.</p><p>Cost of switching is the cost associated with your mitigation strategy. When indebted code is an impediment to sustaining and evolving the functionality of your project, your mitigation strategy is how you go about transitioning away from indebted code in order to reduce or eliminate the impediments. This can entail completely replacing a component with another component, partially replacing a component, or simply small incremental refactorings that accumulate over time. Switching costs are impacted by the size and scope of the component you are replacing, the time you have to spend to find and evaluate commercial and open source alternatives, time spent on custom modifications to the replacement, and time spent on migrating infastructure - for instance, migrating or mapping user data after switching to a different persistence technology.</p><p><strong>The effect of dependencies and encapsulation</strong></p><p>Both switching costs and cost of carry are proportional to encapsulation and dependencies.</p><p>If a technical liability is poorly encapsulated, other components that depend on the indebted component also incur higher switching and carry costs. This is an extremely important concept to understand, and one of the reasons why encapsulation is one of the most important ideas in the history of computing. (If you do not understand or track the dependence structure of your project, you can use a tool such as <a href="http://clarkware.com/software/JDepend.html">jDepend</a> or <a href="http://www.ndepend.com/">nDepend</a>.)</p><p>It is also important to understand that the impact of dependencies on switching costs and cost of carry can be transitive. This means that poor encapsulation of one high-liability component can have profound impact across not only its direct dependents, but also transitive dependencies that are several steps from the indebted component in the dependency graph.</p><p>If a high liability component is not highly volatile, and the costs of switching are high, then making the effort to substitute the component is a low priority. However, dependencies can overrule this judgment because indebted components can impact your cash flows by trickling down into other components that are highly volatile.</p><p>A component may be replaceable with an open source counterpart, but if the use of the component to be replaced is not properly encapsulated, then the switching cost can be quite high. It is important to note that in this case the cost of switching is higher because poor encapsulation itself is a technical liability. Often you have to spend a lot of time paying down that debt before you can consider replacing a component.</p><p>In the <a href="http://alphaitjournal.blogspot.com/2008/08/cross-technical-liabilities-malignant.html">Technical Liabilities</a> article, we talked about benign versus malignant risk. Benign risks are well encapsulated risks in low volatility code. Malignant risks are poorly encapsulated risks, risks in high volatility code, or both. Clearly, the cost of carry on benign risks is far lower than the cost of carry on malignant risks.</p><p><strong>Making trade-off decisions</strong></p><p>You can evaluate different cost of carry vs. cost of switching scenarios by taking the <a href="http://en.wikipedia.org/wiki/Present_value">present value</a> of each cash flow stream for each scenario. You can then compare the <a href="http://en.wikipedia.org/wiki/Net_present_value">net present value</a> of the different scenarios and determine the highest-value course of action. Switching is attractive when the present value of the stream of future cash flows from cost of carry is higher than the present value of the stream of future cash flows from cost of switching.</p><p>The next article in this series will be a field guide for execution that is dedicated to details and examples of using this mental model to make trade off decisions.</p><br /><hr><br /><strong>About Brad Cross:</strong> Brad is a programmer.Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com1tag:blogger.com,1999:blog-123318888665066571.post-1917815862550015582008-11-19T21:19:00.000-08:002009-06-04T21:24:43.081-07:00Pettit - States of IT Governance<p>By Ross Pettit - <em>19 November 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s1600-h/rjp1.jpg"><img id="BLOGGER_PHOTO_ID_5343624959897658850" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s200/rjp1.jpg" border="0" /></a> <p>As we head into a period of economic uncertainty, one thing we can count on is that IT effectiveness will be called into question. This isn’t so much because IT has grown excessively large in recent years, but because of results: industry surveys still show that as many as 60% of IT projects fail outright or disappoint their sponsors. As we head into a downturn, executives may look to IT to create business efficiency and innovation, but they won’t do that until they have scrutinised spend, practices and controls of IT.</p><p>This makes the need for good IT governance more urgent.</p><p>Governance is a curious concept. Governance doesn’t create value, it reduces the likelihood of self-inflicted wounds. It’s taken for granted, and there isn’t a consistent means to show that it actually exists. It is conspicuous only when it is absent, as it is easier to identify lapses in governance than disasters averted. And we tend not to think of an organisation as having “great” governance, but of having “good” or “bad” governance. </p><p>This strongly suggests that “good” is the best that governance gets. It also suggests, as the nursery rhyme goes, that when it is bad, it is horrid.</p><p>Any critical examination of our governance practices will focus on what we do poorly (or not at all) more than on what we do well. But rather than cataloging shortcomings, it is better to start by characterising how we’re governing. This will give us an opportunity to not only assess our current state, but forecast the likely outcome of our governance initiatives.</p><p>To characterise how we govern, we need some definition of the different types or states of governance. To do that, we can categorize governance into one state of “good” and multiple states of "bad."</p><p>We'll start with the bad. The most benign case of “bad” governance is <em>unaligned behaviour</em>. There may be guiding principles, but they're not fully imbued in day-to-day decisions. Individual actions aren't necessarily malicious as much as they are uninformed, although they may be intentionally uninformed. Consider an engineer in a Formula1 team who makes a change to the car, but fails to take the steps necessary to certify that the change is within regulation. This omission may be negligent at best, or a "don't ask / don't tell" mentality at worst. This first category of “bad governance” is a breakdown of participation.</p><p>The next category is <em>naivety</em>. Consider the board of directors of a bank staffed by people with no banking background. They enjoyed outsized returns for many years but failed to challenge the underlying nature of those returns.<sup>1</sup> By not adequately questioning – in fact, by not knowing the questions that need to be asked in the first place – the bank has unknowingly acquired tremendous exposure. This lapse in rigor ultimately leads to a destruction of value when markets turn. We see the same phenomenon in IT: hardware, software and services are subjected to a battery of well-intended but often lightweight and misguided selection criteria. Do we know that we're sourcing highly-capable professionals and not just bodies at keyboards? How will we know that the solution delivered will not be laden with high-cost-to-maintain <a href="http://alphaitjournal.blogspot.com/2008/08/cross-technical-liabilities-malignant.html">technical debt</a>? Naïve governance is a failure of leadership.</p><p>Worse than being naïve is placing complete <em>faith in models</em>. We have all kinds of elaborate models in business for everything from financial instruments to IT project plans. We also have extensive <a href="http://agilemanager.blogspot.com/2008/04/rules-versus-principles.html">rule-based regulation</a> that attempts to define and mandate behaviour. As a result, there is a tendency to place too much confidence in models. Consider the <a href="http://en.wikipedia.org/wiki/Airbus_a380">Airbus A380</a>. No doubt the construction plan appeared to be very thorough when Airbus committed $12b to the program. During construction, a team in Germany and another team in France each completed sections of the aircraft. Unfortunately, while those sections of the aircraft were "done", the electrical systems couldn’t be connected. This created a rather large, expensive and completely unanticipated system integration project to rewire the aircraft in the middle of the A380 program.<sup>2</sup> We see these same phenomenon in IT. We have detailed project plans that are surrogates for on-the-spot leadership, and we organise <a href="http://alphaitjournal.blogspot.com/2008/10/breidenbach-grain-and-icbms.html">people in work silos</a>. While initial project status reports are encouraging, system integration or quality problems seemingly appear out of nowhere late in development. Faith in models is an abrogation of leadership, as we look to models instead of competent leaders to guide behaviour toward results.</p><p>Finally, there is <em>wanton neglect</em>, or the absence of governance. It is not uncommon for organisations to make optimistic assumptions and follow through with little (if any) validation of performance. Especially at the high end of IT, managers may assume that because they pay top dollar, they must have the best talent, and therefore don’t need oversight. People will soon recognise the lack of accountability, and work devolves into a free-for-all. In the worst case, we end up with a corporate version of the United Nation’s <a href="http://en.wikipedia.org/wiki/Oil_for_food#Abuse">oil for food</a> program: there's lots of money going around, but only marginal results to show for it. Where there is wanton neglect of governance, there is a complete absence of leadership.</p><p>This brings us to a definition of good governance. The key characteristics in question are, of course, trust and competent leadership. Effective governance is a function of leadership that is engaged and competent to perform its duties, and trustworthy participation that reconciles actions with organisational expectation. Supporting this, governance must also be transparent: compliance can only be built-in when facts are visible, verifiable, easily collected and readily accessible to everybody. This means that even in a highly regulated environment, reaction can be swift because decisions can be effectively distributed. In IT this is especially important, because an IT professional – be it a developer, business analyst, QA analyst or project manager – constantly makes decisions, hundreds of times over the life of a project. Distributed responsibility enables rapid response, and it poses less of a compliance risk when there is a foundation of trust, competent leadership, and transparency.</p><p>This happy state isn’t a magical fantasy-land. This is achievable today by adhering to best practices, integrating metrics with continuous integration, using an Agile-oriented application lifecycle management process that enables localised decision-making, and applying a balanced scorecard. Good IT governance is in the realm of the possible, and there are examples of it today. It simply needs vision, discipline, and the will to execute.</p><p>In the coming months, we are likely to see new national and international regulatory agencies created. This, it is hoped, will provide greater stability and predictability of markets. But urgency for better governance doesn't guarantee that there will be effective governance, and regulation offers no solution if it is poorly implemented. The launch of new regulatory bodies - and the actions of the people who take on new regulatory roles - will offer IT a window into effective and ineffective characteristics of governance. By paying close attention to this, IT can get its house so that it can better withstand the fury of the coming economic storm. It will also allow IT leaders to emerge as business leaders who deliver operating efficiency, scalability and innovation at a time when it's needed the most.</p><p><sup>1</sup> <span style="font-size:78%;">See Hahn, Peter. “Blame the Bank Boards.” <span style="TEXT-DECORATION: underline">The Wall Street Journal</span>, 26 November 2007.</span></p><p><sup>2</sup> <span style="font-size:78%;">See Michaels, Daniel. “Airbus, Amid Turmoil, Revives Troubled Plane” <span style="TEXT-DECORATION: underline">The Wall Street Journal</span>, 15 October 2007</span>.</p><br /><hr /><br /><p><strong>About Ross Pettit:</strong> Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active <a href="http://agilemanager.blogspot.com/"><strong><span style="font-family:Tahoma;color:#800080;">blogger</span></strong></a> on topics of IT management, governance and innovation. He is also the editor of <a href="http://www.alphaitjournal.com/categories/20080616">alphaITjournal.com</a>.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-40937855639522896302008-11-13T21:12:00.000-08:002009-06-04T21:18:02.169-07:00Cross - Technical Equity<p>By Brad Cross - <em>13 November 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s1600-h/bcross3.JPG"><img id="BLOGGER_PHOTO_ID_5343646599935290498" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s200/bcross3.JPG" border="0" /></a> <p>Recall that previously, we tallied code metrics by component to produce a table of <a href="http://alphaitjournal.blogspot.com/2008/08/cross-technical-liabilities-malignant.html">technical liabilities.</a> Then we scored the degree of substitutability of each component on a scale of 1 to 4 to assign each an <a href="http://alphaitjournal.blogspot.com/2009/06/cross-discovering-assets-and-valuing.html">asset value.</a> To determine <a href="http://www.investopedia.com/terms/s/stockholdersequity.asp">owner's equity</a>, we need to compare asset and liability valuations, which means we need to transform the collection of metrics in the table of technical liabilities into an index comparable to our asset valuation.</p><p><strong>Are you Equity Rich or Over-Leveraged?</strong></p><p>There are two ways we can make this transformation. One is to devise a purely mathematical transformation to weigh all the technical scores into a single metric scaled from 1 to n. To do this, convert each metric to a 100% scale (where 100% is the good side of the scale), sum the scaled values and divide by 100. This will give you a number from 0 to n, with n being the number of metrics you have in your table. Then multiply by 4/n, which will transform your aggregated metric to a scale with a maxiumum of 4. For example, if you have 60% test coverage, 20% percent duplication and 150 bug warnings from static analysis, you can do the following: (1-60%) + 20% + 150/200 = 135% (where 200 is the maximum number of bug warnings in any of your components.) Since we have 3 metrics and we want the final result to be on a 4 point scale, we multiply by 4/3. This gives a score of 1.8 out of 4.</p><p>Alternatively, we can devise a 1-to-4 scale similar to our asset valuation scale. This allows us to combine quantitative metrics with the qualitative experience we have from working with a code base.</p><p>As in finance, excessive liabilities can lead to poor credit ratings, which leads to increasing interest rates on borrowing. In software, we can think of the burden of interest rate payments on technical debt as our cost of change, something that will reduce the speed of development.</p><p>Technical debt, like any form of debt, can be rated. <a href="http://en.wikipedia.org/wiki/Bond_credit_rating">Bond credit ratings</a> are cool, so we will steal the idea. Consider four credit rating scores according to sustainability of debt burden, and how these apply to code:</p><ol><li>AAA - Credit risk almost zero.</li><li>BBB - Medium safe investment. </li><li>CCC - High likelihood of default or other business interruption.</li><li>WTF - Bankruptcy or lasting inability to make payments.</li></ol><p>A <strong>AAA</strong> rated component is in pretty good shape. Things may not be perfect, but there is nothing to worry about. There is a reasonable level of test coverage, the design is clean and the component's data is well encapsulated. There is a low risk of failure to service debt payments. Interest rates are low. The cost of change in this component is very low. Development can proceed at a fast pace.</p><p>A <strong>BBB</strong> component needs work, but is not scary. It is bad enough to warrant observation. Problems may arise that weaken the ability to service debt payments. Interest rates are a bit higher. This component is more costly to change, but not unmanageable. The pace of development is moderate.</p><p>A <strong>CCC</strong> is pretty scary code. Sloppy and convoluted design, duplication, low test coverage, poor flexibility and testability, high bug concentration, and poor encapsulation are hallmarks of CCC-rated code. The situation is expected to deterioriate, risk of interruption of debt payments is high and bankruptcy is a possibility. Interest rates are high. Changes in this component are lengthy, painful, and expensive.</p><p>A <strong>WTF</strong> component is the kind of code that makes you consider a new line of work. Bankruptcy-insolvency is the most likely scenario. Interest rates are astronomically high. An attempt to make a change in this component is sure to be a miserable, slow and expensive experience.</p><p>Expanding on the example we've been using, let's fill out the rest of the balance sheet and see what owner's equity looks like.</p><p><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td style="color:#003366;"><p align="center"><span style="color:#ffffff;"><strong>Component </strong></span></p></td><td style="color:#003366;"><p align="center"><span style="color:#ffffff;"><strong>Assets </strong></span></p></td><td style="color:#003366;"><p align="center"><span style="color:#ffffff;"><strong>Liabilities </strong></span></p></td><td style="color:#003366;"><p align="center"><span style="color:#ffffff;"><strong>Equity </strong></span></p></td><td style="color:#003366;"><p align="center"><span style="color:#ffffff;"><strong>Leverage </strong></span></p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Brokers</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3 </p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">-1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity </p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Data</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">-1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity </p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">DataProviders</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">-1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">DataServer</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Execution</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">FIX</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">4</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">-3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Instruments</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Mathematics</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Optimization</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Performance</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Providers</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Simulation</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3/2</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Trading</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">0</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">Infinity</p></td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">TradingLogic</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">4</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">4</p></td></tr></tbody></table></p><p>This table naturally leads to a discussion of tradeoffs such as rewriting versus refactoring. Components with negative equity and low asset asset value are candidates for replacement. Components with positive equity and middling asset value are not of much interest: while owning something of little value is neither exciting nor worrying, owning something of little value that carries a heavy debt burden is actually of negative utility. Components of high asset value but low equity are a big concern; these are the components we need to invest in.</p><p>In addition to thinking about how much equity we have in each component, we can also think about how leveraged each component is, i.e. how much of a given component's asset value is backed by equity, and how much is backed by liability. This measure of leverage is called the <a href="http://www.investopedia.com/terms/d/debtequityratio.asp">debt to equity ratio</a>. An asset value of 3 with a liability of 2 leaves you with an equity value of 1, and you are leveraged 3-to-1, i.e. your asset value of 3 is backed by only 1 point of equity. Any asset with negative equity has infinite leverage, which indicates a severe debt burden.</p><p><strong>The Technical Balance Sheet Applied</strong></p><p>This exercise makes the decisions we face easier to make. In the example above, there are a number of components with an asset value of 2 and liabilities of 2 or 3. This led me to replace all the custom persistence code with a thin layer of my own design on top of <a href="http://www.blogger.com/www.db40.com">db4o</a> (an embeddable object database.) I deleted the components Brokers and DataProviders, then developed my own components from scratch and extracted new interfaces.</p><p>The FIX component, with an asset value of 1 and liabilities of 4, obviously needed to go. However, although the component has high negative equity, I did some experimenting and found that the cost of removing this component was actually quite high due to proliferation of trivial references to the component. I have gradually replaced references to the FIX component and chipped away at dependencies upon it, and it will soon be deleted entirely.</p><p>There are a number of components with an asset value of 3 or 4 but with liabilities of 2 or 3. These are the most valuable parts of the product that contain the core business code. However, some have 20% or less test coverage, loads of duplication, sloppy design, and many worrisome potential bugs. Due to the high asset value, these components warrant investment. I thought about rewriting them, but in these cases most often the best bet is to pay down the technical debt by incrementally refactoring the code. A subtle bonus from refactoring instead of rewriting is that each mistake in the code reveals something that doesn't work well, which is valuable information for future developement. When code is rewritten, these lessons are typically lost and mistakes are repeated.</p><p>We now have a sense of debt, asset value and technical ownership that we've accumulated in our code base. Our next step is to more fully understand trade off decisions based on weighing discounted cash flows: the cost of carry versus the cost of switching. Or alternatively stated, the cost of supporting the technical debt versus the cost of eliminating it.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-21911172332547306862008-11-12T21:47:00.000-08:002009-06-04T21:59:06.560-07:00Kehoe - Your Performance Is Our Business<p>By John Kehoe - <em>11 December 2008</em><br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s1600-h/kehoe.jpg"><img id="BLOGGER_PHOTO_ID_5343652952609688434" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s200/kehoe.jpg" border="0" /></a>I know of an outfit with the motto of ‘Your Performance is our Business.’ It doesn’t matter what they sell (OK, it’s not for an E.D. product, let’s get that snicker out of the way), it is what the mindset the motto instills: ‘You’ve got IT problems with a real impact to business, and we have a solution and are focused on your business needs’. It got me thinking, what mindset is at work at our IT shops? What would an IT shop look like with a performance mindset? </p><p>The meaning of the mindset varies by how we define performance to our customers. Some shops have a simple requirement. I can’t count the times I find the critical application is Email. It is a straightforward domain of expertise, albeit with significant configuration, security and archiving requirements. The key metrics for performance are availability, responsiveness and recoverability. Not an insurmountable challenge except in the most complex of deployments. </p><p>There isn’t much performance to provide for messaging outside of availability and responsiveness. There isn’t alpha to be found. It’s a cost center, an enablement tool for information workers.</p><p>Performance comes into play with alpha projects. These are the mission critical, money making monstrosities (OK, they aren’t all monstrosities, but the one’s I’m invited to see are monsters) being rolled out. This is very often the realm of enterprise message busses, ERP and CRM suites, n-tier applications and n-application applications (I like the term n-application applications, I made that one up. My mother is so proud). All are interconnected, cross connected or outside of your direct control. Today, the standard performance approach is enterprise system management (ESM). These are the large central alerting consoles with agents too numerous to count. ESM’s approach the problem from the building blocks and work their way up. </p><p>This is not the way to manage performance.</p><p>The problem with low level hardware and software monitoring approach is that performance data cannot be mapped up to the transaction levels (yes, I said it; consider it flame bait). Consider the conventional capacity planning centers we have today. The typical approach is to gather system and application statistics and apply a growth factor to it. The more sophisticated approach uses additional algorithms and perhaps takes sampled system load to extrapolate future performance. The capacity planning model lacks the perspective of the end user experience. </p><p><strong>The need for Transaction Performance Management (TPM)</strong></p><p>TPM looks at the responsiveness of discrete business transactions over a complex application landscape. Think of this in the context of n-application applications: TPM follows the flow regardless of the steps involved, the application owner or “cloud” (did I ever say how much I loathe the term cloud?) The TPM method follows the transaction, determines the wait states and then drills into the system and application layers. Think of it as the inverse of ESM. </p><p>To exploit the TPM model you need a dedicated performance team. This is a break from the traditional S.W.A.T. team approach for application triage and the mishmash of tools and data used to ‘solve’ the problem. In a <a href="http://alphaitjournal.blogspot.com/2009/06/kehoe-so-i-get-this-call.html">previous column</a>, we discussed the implications of that approach, namely long resolution time and tangible business costs.</p><p>What would a TPM team look like?</p><ol><li>We need a <em>common analysis tool and data source </em>monitoring<em> </em>the application(s) architecture. This is essential to eliminate the ‘Everybody’s data is accurate and shows no problems, yet the application is slow’ syndrome.</li><li>We need to <em>look at the wait states</em> of the transactions. It isn’t possible to build up transactions models from low level metrics. The ‘bottom up’ tools that exist are complex to configure and rigid in the definition of transactions. They invariable rely on a complex amalgamation of multiple vendor tools in the ESM space. Cleanliness of data and transparency of transactions are hallmarks of a TPM strategy.</li><li>We need <em>historical perspective</em>. Historical perspective provides our definition of ‘normal’. It drives a model based on transaction activity over a continuous time spectrum, not just a performance analysis at a single point in time. </li><li>We need <em>ownership and strong management</em>. TPM implementations don’t exist in a vacuum, they cannot be given to a system administrator on an ‘other duties’ priority. TPM implementations require a lot of attention. They are not a simple profiler we turn on when applications go pear shaped. Systems, storage and headcount are needed, subject matter experts retained and architects available. Management must set the expectation that TPM is the endorsed methodology for performance measurement, performance troubleshooting and degradation prevention.</li><li>TPM must <em>quickly show value</em>. Our team and implementation must be driven by tactical reality with a clear relationship to strategic value. We need to show quick performance wins and build momentum. For instance, there needs to be a focus on a handful of core applications, systematically deployed and showing value. Build success from this basis. Failure is guaranteed by the big bang global deployment or a hasty deployment on the crisis <em>du jour</em>.</li><li>There must be <em>a core user community</em>. Our user community consists of people up and down the line, using the tool for tactical problem solving to high level business transaction monitoring. These people know the application or the costs to the business. Training is essential to an organization-wide TPM buy-in.</li><li>TPM must be embraced by the whole application lifecycle. It’s not enough to have operations involved. QA, load testing and development must be active participants. They can improve the quality of software product early on using the TPM methodology. </li></ol><p>An example of a TPM success is a web based CRM application I worked on recently. The global user population reported poor performance on all pages. The TPM team saw isolated performance issues on the backend systems, but they did not account for the overall application malaise. The supposition was that last mile was too slow or that the application was too fat. We implemented the last TPM module to analyze the ‘last mile’. It turns out each page has a single pixel GIF used for tracking. This GIF was missing and caused massive connect timeouts for each page. Put the image in the file system and the problem disappeared. This begs the question: how would we have found this problem without the TPM approach?</p><p><strong>TPM and Alpha</strong></p><p>This TPM model sounds great, but what is the practical impact? Has anyone done this and had any bottom-line result to show for it? Many shops have succeeded with the approach. Here are two examples.</p><p>In the first one, a major American bank (yes, one that still exists) wrote a real-time credit card fraud detection application. The application has to handle 20,000 TPS and provide split second fraud analysis. Before we implemented the TMP model, the application couldn’t scale beyond 250 TPS. Within weeks of implementing TPM, we scaled the application to 22,500 TPS. This was a $5mm development effort that prevented $50mm in credit card fraud. The TPM implementation was $100k and done within development. </p><p>The second is one of the top five global ERP deployments. The capacity planning approach forecast 800 CPU’s would be needed over two years to handle the growth in application usage. The prior year, a TPM center was established that performs ruthless application optimization solely based on end user response times and transaction performance. The planning data from the TPM center indicated the need for 300 CPU’s. The gun shy (hey, they’ve only been active a year) TPM center recommended 400 CPU’s. The reality was that only 250 CPU’s were needed when the real world performance of the application was measured and tuned over the subsequent year. The company saved $25mm in software and hardware upgrades. The savings provided the funds for a new alpha-driving CRM system that helped close $125mm in additional revenues over two years. </p><p>What is the cost of implementing a TPM center at a large operation? A typical outlay is $2mm including hardware, software, training, consulting and maintenance. An FTE is required as well as time commitments from application architects and application owners. Altogether we can have a rock solid TPM center for the price of a single server: the very same server we think we need to buy to make that one bad application perform as it should. </p><br /><hr /><br /><p><strong>About John Kehoe: </strong>John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at exoticproblems@gmail.com.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-73127853271205187672008-11-06T21:04:00.000-08:002009-06-04T21:16:32.257-07:00Cross - Discovering Assets and Valuing Intangibles<p>By Brad Cross <em>6 November 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s1600-h/bcross3.JPG"><img id="BLOGGER_PHOTO_ID_5343646599935290498" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsP_hdmkYhoHvUTrsRCPcdWYDtUpn7Jr1rU9KBwFCMjsJDCmEhbpvZ5PZjqStNxoDqqKUHFvCpWzLqCN7IcyZsMTqRUFzyEQcLikO3QscbD9LZ_420mHLUTtk7md0O5aYxxnkz8A09KEc/s200/bcross3.JPG" border="0" /></a> <p>In the last <a href="http://alphaitjournal.blogspot.com/2008/08/cross-technical-liabilities-malignant.html">article</a> in this series, we identified our technical liabilities by component, with each component representing a functional area. Now we will do the same with the asset side of the balance sheet.</p><p>The way a code base is structured determines the way it can be valued as an asset. If a code base matches up well to a business domain, chunks of code can be mapped to the revenue streams that they support. This is easier with software products than supporting infrastructure. Sometimes it is extremely difficult to put together a straightforward chain of logic to map from revenue to chunks of the code base. In situations like this, where mapping is not so obvious, you have to be a bit more creative. One possibility is to consider valuing it as an intangible asset, following practices of <a href="http://en.wikipedia.org/wiki/Goodwill_(accounting)">goodwill accounting</a>.</p><p>An even more complicated scenario is a monolithic design with excessive interdependence. In this case, it is very difficult to even consider an asset valuation breakdown, since you cannot reliably map from functional value to isolated software components. This situation is exemplified by monolithic projects that become unwieldy and undergo a re-write. This is a case where bad design and lack of encapsulation hurt flexibility. Without a well encapsulated component-based design, you can only analyze value at the level of the entire project.</p><p><strong>Substitutability as a Proxy for Asset Valuation</strong></p><p>One way to think about asset valuation is <em>substitutability.</em> The notion of code substitutability is influenced by Michael Porter's <a href="http://www.quickmba.com/strategy/porter.shtml">Five Forces model</a>, and is similar to the economic concept of a <a href="http://en.wikipedia.org/wiki/Substitute_good">substitute good.</a> Think of code components in a distribution according to the degree to which they are cheap or expensive to replace. "Cheap to replace" components are those that are replaceable by open source or commercial components, where customization is minimal. "Expensive to replace" components are those that are only replaceable through custom development, i.e. refactoring or rewriting.</p><p>Substitutability of code gives us four levels of asset valuation that can be rank ordered:</p><ol><li>Deletable (lowest valuation / cheapest to replace)</li><li>Replaceable</li><li>Valuable</li><li>Critical (highest valuation / most expensive to replace)</li></ol><p>Consider a collection of software modules and their corresponding valuation:</p><p align="center"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td border bg style="color:#003366;"> </td><td border bg style="color:#003366;"><strong><span style="color:#ffffff;">Module</span></strong></td><td border bg style="color:#003366;"><strong><span style="color:#ffffff;">Substitutibility</span></strong></td><td border bg style="color:#003366;"> </td><td border style="color:#003366;"><strong><span style="color:#ffffff;"> </span></strong></td><td bordercolor="#003366" bgcolor="#003366"> </td><td bordercolor="#003366" bgcolor="#003366"><strong><span style="color:#ffffff;">Module</span></strong></td><td bordercolor="#003366" bgcolor="#003366"><strong><span style="color:#ffffff;">Substitutibility</span></strong></td><td bordercolor="#003366" bgcolor="#003366"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Brokers</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Mathematics</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Data</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Optimization</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">DataProviders</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Performance</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">DataServer</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">2</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Providers</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Execution</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Simulation</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">FIX</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">1</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Trading</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr><tr><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">Instruments</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">3</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366"> </td><td bordercolor="#003366" bgcolor="#cccccc"> </td><td bordercolor="#003366" bgcolor="#cccccc">TradingLogic</td><td bordercolor="#003366" bgcolor="#cccccc"><p align="center">4</p></td><td bordercolor="#003366" bgcolor="#cccccc"> </td></tr></tbody></table></p><p> </p><p> </p><br /><p>A <strong>critical</strong> component is top level domain logic. In the example table, only the trading logic component is critical. This component represents the investment strategies themselves - supporting the research, development, and execution of trading strategies is the purpose of the software.</p><p>A <strong>valuable</strong> component exists to support the top level domain logic. Here, there is a trading component that supports the trading logic by providing building blocks for developing investment strategies. There is also a simulation component that is the engine for simulating the investment strategies using historical data or using <a href="http://en.wikipedia.org/wiki/Monte_carlo_method">Monte Carlo methods</a>. You can also see a handful of other components that provide specialized support to the mission of research, development and execution of investment strategies.</p><p>A <strong>replaceable</strong> component is useful, but it is infrastructure that can be replaced with open source or commercial component. Things in this category include homegrown components that could be replaced by other open source or commercial tools. Components in this category may do more than off-the-shelf alternatives, but an off-the-shelf replacement can be easily modified to meet requirements. In the example above you can see four components in this category. They are related to APIs, brokers, or the persistence layer of the software. Both broker APIs and persistence are replaceable by a wide variety of different alternatives.</p><p>A <strong>deletable</strong> component is a component from which little or no functionality is used, allowing us to either delete the entire thing, or extract a very small part and then delete the rest. This includes the case when you "might need something similar" but the current implementation is useless. In the example, there is an entire component, “Providers,” which is entirely useless.</p><p><strong>Accepting Substitution</strong></p><p>It is important to consider psychological factors when making estimates of value. Emotionally clinging to work we have done in the past will derail this process. For example, perhaps I have written a number of custom components of which I am very proud. Perhaps I think that work is a technical masterpiece, and over time I may have convinced others that it provides a genuine business edge. If we can't put our biases aside, we talk ourselves into investing time into code of low value, and we miss the opportunity to leverage off-the-shelf or open-source alternatives that can solve the same problem in a fraction of the time. </p><p>In this article we've defined a way to identify our assets by business function and to value them either based on a relationship to revenue streams or by proxy using their degree of substitutability. In the next installment, we’ll take a look at switching costs and volatility to set the stage for thinking in terms of cash flows when making trade-off decisions in our code.</p><br /><hr /><br /><p><strong>About Brad Cross:</strong> Brad is a programmer. </p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-29068292476531626982008-10-29T21:02:00.000-07:002009-06-04T21:07:13.656-07:00Breidenbach - Grain and ICBMs<p>By Kevin E. Breidenbach - <em>29 October 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj10-sHRQUPKCoJmAxwywU0W8iCvEPUuebkr1g9nIgExQ0kvssZUcuFHvNSnnxP-GKELK9UBsZdmeT8Vq4e2au8XQY5kHVO43p6YyA7BOWqeaJa8v0q40z-Sw4QvrFzsbYBJkH0FcIp0bo/s1600-h/breidenbach.JPG"><img id="BLOGGER_PHOTO_ID_5343679938901742706" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj10-sHRQUPKCoJmAxwywU0W8iCvEPUuebkr1g9nIgExQ0kvssZUcuFHvNSnnxP-GKELK9UBsZdmeT8Vq4e2au8XQY5kHVO43p6YyA7BOWqeaJa8v0q40z-Sw4QvrFzsbYBJkH0FcIp0bo/s200/breidenbach.JPG" border="0" /></a> <p>As you drive around the countryside of the Midwestern United States, you'll see silos towering over farmland. Depending on the time of year they may even be filled with grain. If you know where to look you might even be able to find a subterranean silo which housed one or more <a href="http://en.wikipedia.org/wiki/LGM-30_Minuteman">Minuteman ICBMs</a> from the days of the cold war. In either of these cases the silos are used for a good purpose – to keep things in that either feed people or vaporize them!</p><p>For some reason though, there is a group out there that like to fill silos full of people. Even stranger is the fact that these people all work together but they may be put in different silos. It's really difficult to talk across silos, so nobody really knows what the people in the other silos are doing.</p><p>So who makes up this weird group that like to segregate people? After studying this group in the wild, researchers have named them <em>Technicilli Managerius</em>, or Technical Managers to us common folk.</p><p>In all seriousness this has been a problem for a long time. As an example, consider a large application that has many different major components. When the system is being designed, the managers often see benefits in creating individual teams to work independently on each component, with each team having its own manager, development leader and several developers. The teams start building their components and everything is dandy, but apart from the odd conversation over a beer between different team members, communication between silos is minimal. And this is where the problems begin.</p><p>If one team is having problems, it is unlikely that other teams will know about it. Different teams may very well be struggling with the same problem and coming up with different – even incompatible – solutions. Or they can play a game where each team waits for another to signal “defeat” and admit to being behind schedule. This defaults the entire application team into delay, giving everybody more time to complete their work – or simply another chance to play the game.</p><p>This inter-team disconnect is particularly prevalent in waterfall projects, which are far from transparent. Of course, the problem isn’t unique to waterfall; it can happen to any project. Agile teams have metrics such as burn down and velocity that allow us to see where they are, and across a large program of work this gives very good insight into which teams are behind schedule. But visibility doesn’t address the underlying problems of teams working in silos: multiple teams will still be working independently of each other.</p><p>I believe that fluidity of people across teams would improve communications and benefits the project as a whole. How would this work? Each major component has its own iteration manager and possibly a lead developer (although I'm becoming convinced that there is really no need for lead developers and a flat structure really is better). A developer can, when needed, move among component teams. In this structure, the "team" exists at the application level and not at the component level.</p><p>It can be argued that this fluidity is difficult to manage, and that developer ramp-up on each component is time consuming, both of which will impact timelines. These are valid points, but they don’t make a compelling counter-argument to trying this approach. If you have competent developers on your team, if there is nothing drastically different in the design of each component, and if there aren’t very different languages for each component, then developers moving among components shouldn’t be too much of a problem. Of course, not every developer may want to move between components, and they shouldn't be forced to make a move. But most developers are inquisitive enough to want to see what is going on in different components.</p><p>Another way to combat silos is through consistent, highly focused communications within and across teams. For example, a good development team holds daily stand-up meetings. They’re a great way to concisely communicate what people are doing and the problems they’re facing. While it isn't possible to bring a very large application team together for a stand-up, there is nothing to stop iteration managers from having regular stand-up meetings to inform each other of what their teams are doing and what problems they are facing.</p><p>Leave silos to grain and thermonuclear weapons: they are much better suited to that working environment than people. Development teams just get tunnel vision and projects end up badly disabled and sometimes dead. Plus, silos look terribly uncomfortable!</p><br /><hr><br /><p><strong>About Kevin Breidenbach:</strong> Kevin has a BSc in computer science and over 15 years of development experience. He has worked primarily in finance but has taken a few brief expeditions into .com and product development. Having professionally worked with assembly languages, C++, Java and .Net he's now concentrating on dynamic languages such as Ruby and functional languages like Erlang and F#. His agile experience began about 4 years ago. Since that time, he has a serious allergic reaction to waterfall and CMM.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-9668980996486104512008-10-22T20:58:00.000-07:002009-06-04T21:01:53.784-07:00Pettit - Volatility and Risk of IT Projects<p>by Ross Pettit - <em>22 October 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s1600-h/rjp1.jpg"><img id="BLOGGER_PHOTO_ID_5343624959897658850" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiusxzXKKxgIrQp22KLVkP8TRCogoPWoOOChcE1bT2rA4jQg92b646DHEfyo6mvCOPtGLoR1KVVI3I2S_CvSVgOXEdM6q8txQCijTkpdDhAU0a7uQghcv3eOReGmvCTL5R_fYlpZ0oqHiA/s200/rjp1.jpg" border="0" /></a> <p>When we plan IT projects, we forecast what will be done, when we expect it will be done, and how much it will cost. While we may project a range of dates and costs, rarely do we critically assess a project’s <em>volatility.</em></p><p><a href="http://www.investopedia.com/terms/v/volatility.asp">Volatility</a> is a measure of the distribution of returns. The greater the volatility, the greater the spread of returns, the lower the expected value of the investment.</p><p>In finance, volatility is expressed in terms of price. In IT projects, we can express volatility in terms of time, specifically the length of time that a project may take. Time is a good proxy for price: the later an IT asset is delivered, the later business benefit will be realised, the lower the yield of the investment.</p><p>Using <a href="http://en.wikipedia.org/wiki/Monte_Carlo_method">Monte Carlo simulation</a> we can create a probability distribution of when we should expect a project to be completed. DeMarco and Lister’s <a href="http://www.systemsguild.com/riskology/">Riskology</a> tool calculates a probability curve of future delivery dates. It allows us to assess the impact of a number of factors such as staff turnover, scope change, and productivity on how long it will take to deliver. In addition to projecting the probability of completion dates, the Riskology tool will also calculate the probability of project cancellation. The inclusion of <a href="http://www.investopedia.com/terms/t/tailrisk.asp">fat tail</a> losses makes this a reasonably thorough analysis.</p><p>Monte Carlo simulation gives us both an average number of days to complete a project and a variance. Using these, we can calculate the <a href="http://www.investopedia.com/terms/c/coefficientofvariation.asp">coefficient of variation</a> to get an indicator of project variability.</p><div align="center">Standard Deviation (days)</div><div align="center">CV = ------------------------------------------------</div><p align="center">Average (days) to complete the project</p><p>The coefficient of variation is a metric of project variance. The higher the CV, the greater the volatility, the greater the risk there is with the investment.</p><p>Historical project data allows us to put a project's CV in context. Suppose we have metrics on prior projects that show the projects IT does for Accounting have an average variance of 1 day late for every 10 days of plan, with a variance of 0.5 days. Suppose further that a new project expected to last 6 months is forecast to be 6.5 days late with a variance of 3 days. Somewhat akin to assessing the <a href="http://www.investopedia.com/terms/b/beta.asp">Beta</a> (although it is not calculated entirely from historical data), this comparison allows the IT project investor to ask piercing questions. What makes us think this project will be different from others we have done? Why do we think the risk we face today is so much different than it has been in the past?</p><p>It is appealing to think that by supplying some indication of the volatility and Beta we’re giving investors in IT projects a complete picture, but there are limits to what this tells us. Our risk assessment is only as good as our model, and our model will be laden with assumptions about people, capabilities, requirements and opportunity. What if we fail to completely identify and properly anticipate both probability and impact of the risks that we are so carefully modeling? Come to think of it, isn’t this what got Wall Street into so much trouble recently?</p><p>Risk management is a primitive practice in IT. All too often, it is little more than an issue list with high/medium/low impact ratings. Typically, risks are neither quantified nor stated in terms of impact to returns. Worse still, because they’re simply lists in spreadsheets, they’re often ignored or denied. This means that the IT project manager is focused on internal risks, such as technology challenges or days lost due to illness. They don't pay much attention to external risk factors such as a regionally strong tech economy that threatens to lure away top talent, or a supplier teetering on the edge of receivership. By quantifying the impact of risks – both individually and collectively – the project manager comes face-to-face with the broader environment on a regular basis.</p><p>Focusing on volatility also makes it obvious that the “on time and on budget” goal is achieved not so much by what goes right as much as by what doesn’t go wrong. That, in turn, strongly suggests that being "on time and on budget" is a misdirected goal in the first place. It also suggests that traditional project management has less to do with project success than we might think.</p><p>Let’s consider why. Traditional IT manages to the expectation that everything can and should go according to plan. Changes in scope, changes in staff, and even mistakes in execution are treated as exceptions. Traditional IT management looks to reconcile all variations to plan and will attempt to do so even when the sum of the variations – 100% staff turnover, 100% requirements change – creates a completely new project. The traditional IT project manager is trying to maximise <em>effort</em> for available <em>budget</em>: “the project will be on time, what might go wrong to make it late, and what must we do to compensate.”</p><p>By comparison, Agile project management expects change. It focuses on reducing volatility by <a href="http://alphaitjournal.blogspot.com/2008/07/spillner-big-projects-small-increments.html">making deliveries early and often</a>. The Agile project manager is trying to maximise <em>yield</em> given available <em>time</em>: “the project will be late, what can we do to bring it forward, and what can we do to reprioritise.” This is a subtle - but critical - shift in thinking that moves risks from the fringe to the center of the frame.</p><p>Risk analyses are supplements to, not replacements of, good management. Risk models are abstractions. No risk model will capture every last exposure. Assumptions in underlying numbers will be wrong or arrived at inexpertly. Worse still, they can be gamed by participants to tell a particular story. All this can lead to poor investment decisions and ultimately investment failure. Still, while working in blind adherence to risk models is hubris, working without them is reckless. Investment managers (or in IT, project managers) are paid for their professional judgment. Investors (IT project sponsors) are responsible to audit and challenge those entrusted with their capital. What managers and sponsors do pre-emptively to ensure project success is far more complete when risk analyses are brought to bear.</p><p>The higher the expected yield of an IT project, the more important it is to be aware of volatility. If volatility isn't quantified, the project lacks transparency, and its investors have no means by which to assess risk. This leads to a misplaced confidence in IT projects because long-term success is assumed. If the recent financial turmoil has taught us anything, it's that we can assume nothing about our investments. </p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-14832231348201830242008-10-15T20:52:00.000-07:002009-06-04T20:57:09.287-07:00Kehoe - The German General Staff Model and IT Organizations<p>By John Kehoe - <em>15 October 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s1600-h/kehoe.jpg"><img id="BLOGGER_PHOTO_ID_5343652952609688434" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px; hspace: " alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi0O5qrfBlahe41a0hJwTAf8vf219jVOrhKpHzTheDtoI8l045JNUCF78Yg5ce8FmRsEgUnbiUrQ_5rN9bhMp679f7FHHdyYJpUH3HFe8IBUpZ1XTxB7LmM9H8sc0Ee409mVzADb35DIA/s200/kehoe.jpg" border="0" /></a> <p>A couple of stories caught my eye this month and dovetail with a model I’m investigating. First, a column, <a href="http://management.silicon.com/itdirector/0,39024673,39285811,00.htm">Meet the IT Guy</a>, outlines the typical, hackneyed view of the IT archetype (still funny stuff). The second, an excerpt from <a href="http://www.businessweek.com/magazine/content/08_36/b4098032904806.htm">Numerati in Business Week</a>, examines <a href="http://www.ibm.com/">IBM’s</a> effort to model consultant abilities and cost to map the right people to the right job and model how a successful expert is created (neat for high level experts, but a bit scary for lower level consultants).</p><p>This leads me to the characteristics an IT organization needs to excel. Curiously enough, they are descendents of the <a href="http://en.wikipedia.org/wiki/German_general_staff">German General Staff</a> (GGS) from the period between 1814 and 1900).</p><p><strong><span style="font-size:85%;">Staffing Model</span></strong></p><p>The German General Staff (GGS) was created at the end of the <a href="http://en.wikipedia.org/wiki/Napoleonic_Wars">Napoleonic Wars</a> as a reaction to the military officer corps being staffed by men who purchased their positions. The "commissioned" officers (as in, paid for their commission) were on a quest for personal glory. As a result, they fought by rote, did not create new strategies, got a lot of men killed and wasted resources. The GGS mission was to create a professional officer corps to change that mindset and with it, achieve better results.</p><p>Candidates for the GGS were rigorously vetted for competency and motivation before an invitation was extended. Once in, GGS officers were categorized in two dimensions: motivation and competency. This can be represented in a 2 x 2:</p><p></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTa5LWgdPGcIVFvDlnvFx63eCR4I8hWrwjidHh4QuQ4QdUeOox8LQ0hQ53XF0qJtZyuoXmV7qTHYnSd4TqZzFQsu4iK-EZ7oD3bmkSPz1oxF_cW8hWMo0zgcHsc506kgLaY3fls0yAeVo/s1600-h/GGS1.jpg"><img id="BLOGGER_PHOTO_ID_5343686858577298194" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 386px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTa5LWgdPGcIVFvDlnvFx63eCR4I8hWrwjidHh4QuQ4QdUeOox8LQ0hQ53XF0qJtZyuoXmV7qTHYnSd4TqZzFQsu4iK-EZ7oD3bmkSPz1oxF_cW8hWMo0zgcHsc506kgLaY3fls0yAeVo/s400/GGS1.jpg" border="0" /></a><br /></p><p>This is how the GGS staffed the right person for the right role.</p><p>Clearly, in any organization, a mismatch breaks the lot. Play the mental exercise of putting your people in these positions. It is easy to find an implementer in a manager position or a manager in the general’s seat. Recognizing the mismatch makes obvious why things bog down or spin out of control.</p><p><strong><span style="font-size:85%;">Organizational Values</span></strong></p><p>The GGS instilled the following values in its members:</p><ul><li><em>Dedication:</em> By investing in an individual, that individual is more committed to the organization</li><li><em>Motivation:</em> Devise good strategies that are efficient, flexible and victorious</li><li><em>Dissemination:</em> Get the ideas into the field</li><li><em>Doctrine:</em> Get a common process in play</li><li><em>Innovation:</em> Think outside the box to adjust to the circumstances</li><li><em>Philosophy:</em> How do we go about our business? What are the ways and means we chose to use or not use.</li></ul><p>Now, why put forward the GGS as a role model? Because the Germans where the first to do it. Today, every major nation has some sort of joint military command and training structure. In order for a military to succeed in a campaign, it must leverage every resource to maximum productivity and align tactical activities with strategic goals. The most successful operations – the most successful businesses – have the concept ingrained from top to bottom.</p><p>This approach makes clear how important it is to place each person to his or her abilities. Suppose a junior level person is designing a technical architecture for performance management. This mismatch is a high risk for the organization and the individual. Don’t axe the person because they perform poorly, move him or her to a task commensurate with their ability. Make clear that this move is not a punishment, just a rebalancing of the skills portfolio. If, however, a person falls into the lazy/incompetent quadrant, well, you know what to do.</p><p>Another interesting characteristic of the GGS is that it rotated people off the line into staff positions, and then back to the line. Many IT organizations have one set of people who put code into production and a cadre of architects in staff (or non-line) positions. Or they have people managing projects in their own way, ignoring efforts of a central PMO to create consistent and professional PM practices. Either is an example of an organizational separation within IT, with “central office” people on one side and “executors” on the other. By rotating people in and out of staff positions, IT policies are more likely to be actionable and not academic. There is also more likely to be buy-in and not resistance to IT standards. Perhaps less obvious, it contains the expansion of IT overhead as there are few career "staffers:" everybody will be back to the line before long. Finally, it makes IT less of a cowboy practice, and more of a professionally executing capability.</p><p><strong><span style="font-size:85%;">Mapping the Concepts</span></strong></p><p>How do we map the GGS to an organization to measure its potential?</p><ul><li><em>Dedication</em> is obvious by the rate of employee exit and replacement. IT is a highly mobile profession; "healthy" IT organizations will have 15% turnover or less. </li><li><em>Motivation</em> is recognized by the creation of value, not the number of overtime hours worked. Do we deliver in a timely fashion? Are we receptive to other organizations? Do we know and appreciate the impact of our action and inaction?</li><li><em>Dissemination</em> is judged by joint cooperation. Do tasks get done in a timely fashion across a joint team? Do people know the resources and responsibilities around them?</li><li><em>Doctrine</em> can be summed up simply by asking: do rules define the exceptions or do exceptions define the rules? If our rules are exception based, we have a problem. We have multiple options and cannot rationally consider their impact.</li><li><em>Innovation</em> is the game changer that gets us ahead of the competition. What can we change that drives revenue or improves margins?</li><li><em>Philosophy</em> defines the actions we accept and reject. What motivations do we accept or reject? Are they telegraphed throughout the organization? For instance, we should have profitability as our guide. How to we achieve it, growth or cost cutting. Does advantage come from outsourcing or offshoring? How do we balance the other 5 values? </li></ul><p>The GGS was not a rarified career opportunity devoid of delivery expectations and obligations, but provided a means by which to circulate expertise and provide experience. It offers IT a straightforward way to fashion planning and career development, as well as a means to incubate ideas and individuals. It starts with a clean sheet of paper, a cup of coffee and insight into your business, organization and services portfolio. Give it a try today.</p><br /><hr /><br /><p><strong>About John Kehoe: </strong>John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at exoticproblems@gmail.com.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-55445824299632840312008-10-08T20:48:00.000-07:002009-06-04T20:55:56.690-07:00Ververs - Generation Y: Enabling Autostart<p>By Carl Ververs - <em>8 October 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglQET-x95oDd83mia_XJAp6a2hAyZjnZ-jLpxSEKI-uMTRVCuEaA1a7g3FJwDnzXIXxKVn-G1Qf1Lg5apO5WtV41ylOKMPQ5D8TrUm6umXSSlUoirbzsaI5qKAGuy-wHVD59e-Bp2UDEY/s1600-h/ververs.jpg"><img id="BLOGGER_PHOTO_ID_5343639697043836450" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglQET-x95oDd83mia_XJAp6a2hAyZjnZ-jLpxSEKI-uMTRVCuEaA1a7g3FJwDnzXIXxKVn-G1Qf1Lg5apO5WtV41ylOKMPQ5D8TrUm6umXSSlUoirbzsaI5qKAGuy-wHVD59e-Bp2UDEY/s200/ververs.jpg" border="0" /></a> <p>A pack of Millennials sit in a conference room. The phone rings. Says one to the next: “Dude, you gonna get that?”, Says the other: “Like, Yah! And get, like reprimanded, or something!”. Five minutes later their manager storms in, yelling: “Why aren’t you picking up the phone??!?! I was wondering where you were!” Says one in reply: “We didn’t know we were supposed to!”</p><p>This would be cute if it were just a joke. But this is the life of managers of Millennials.</p><p>When compared to previous generations, <a href="http://en.wikipedia.org/wiki/Generation_Y">Generation-Y</a> comes off as a bunch of lazy, indecisive airheads. But there is more to it than that. And after a bit of closer examination, you will find that the Gen-Y attitude has some real advantages.</p><p>Millennials didn’t jump on their Facebooks and collectively decide to give every prior generation a hard time. Their work attitudes have a clear origin: the overzealous, results-driven approach to child rearing that their parents have practiced. Like many things in their lives, <a href="http://en.wikipedia.org/wiki/Generation_Jones">Late Boomers</a> and <a href="http://en.wikipedia.org/wiki/Generation_X">Gen-X</a> couldn’t just enjoy their children, they were to be made projects, with a results baseline and earned-value metrics. Consider a recent remark overheard from a mother of a 5-year old: “Jason still can’t write a full sentence. I’m considering occupational therapy.”</p><p>The cause for excessive parent involvement may be rooted in their investment approach to raising their children. In a <a href="http://www.sun-sentinel.com/features/lifestyle/sfl-helicopter-parents-0909,0,1153578.story">Chicago Tribune article</a> from September 9th, 2008, a <a href="http://en.wikipedia.org/wiki/Helicopter_parent">helicopter parent</a> justifies her behavior by saying that she feels parents must stay involved in their children’s life in college to make the $200K investment worthwhile. This cynical perspective will not be lost on the “assets” and will no doubt make them feel reduced to Boomer accessories (that is, if the dual-career-hound, passed-off-to-sitters pattern hasn’t done so already). There is, not surprisingly, an entrenched defense for helicopter parenting, as a <a href="http://www.collegeparents.org/cpa/resource-current-campus-helicopter.html">CPA article</a> from September 2006 shows.</p><p>As involved and engaged as these parents have been with their offspring, they have missed something crucial: their children can actually think for themselves and have drawn the conclusion that, like all generations before them, their parents are wrong. They have revolted against the workaholic, asset-oholic, keeping-up-with-the-Gateses attitude and are simply rejecting the now-bankrupt notion that personal success is measured by how much stuff one has. "Turn on, tune in, drop out" has been replaced with "iTune in, Log on, Check out your friends’ Twitter updates."</p><p>Millennials demand a better work/life balance. There are several advantages to this. For starters, they are less likely to burn out. They have to be very efficient to complete the work assigned to them. They tend to get auxiliary work input from multiple communications channels. Rather than working long hours, they challenge the status quo, demanding (as they should) solutions to lingering problems that create the need for excessive work hours.</p><p>However, an inflexible attitude to working late can make them unreliable in crisis situations. Evening and weekend work is sometimes necessary. A Gen-Y person in a key role unwilling to put in the effort when it is needed most can mean that deadline-driven work languishes and projects are delayed. Striking a compromise is difficult. A developer on one of my teams had no higher priority than running. He was consistently late with his work, which was often also incomplete. We agreed to small, very concrete deliverables. While they were completed properly, the experience left me feeling like I was micromanaging and impeding his growth.</p><p>While Millennials want to have a life, they also want to have a meaningful job. They want their ideas to be heard and their opinions to count. The upshot of this is that bright minds will not go to waste. Staff can be motivated by big ideas and by seeing clearly how they contribute to revenue. But youthful enthusiasm often gets dismissed as daydreaming, discredentializing fresh insights. Millennials must be taught that most people don’t “get” new ideas at first. Promoting and realizing them requires discipline and tenacity.</p><p>A bigger problem is the sense of entitlement Gen-Y, and to a greater extent <a href="http://en.wikipedia.org/wiki/Generation_I">Gen-I</a>, feels. They expect everything to be on-demand and immediate. If something requires application, study and practice, it’s dismissed, considered to be not worth the effort. This puts Gen-Y at a disadvantage with people from other cultures who have not followed the Western patterns of generations. In the West, the mantra is "work smarter, not harder." But some skills cannot be obtained without actual practice. And without practice, one has to work harder to obtain a similar result as a skilled worker. To make things worse, the stimulus for Millennials, and Generation-I to try harder is muted by being told that “everyone is special”. In the infamous words of <a href="http://en.wikipedia.org/wiki/Dash_Parr">Dash Parr</a>: “If everybody’s special, nobody is.” See also the <a href="http://cerebraldad.blogspot.com/2008_02_01_archive.html">Cerebral Dad’s</a> point of view on this.</p><p>Do not expect Gen-Y to share your habit of getting up at 5:30, checking the market, wolfing down a processed breakfast and getting to work by 7:30. Just because Jack So-and-so or Rupert Whatisname did things that way means nothing to these kids. “Legendary CEOs” aren't Gen-Y role models; they want to be like the Google guys.</p><p>So what can we do with all this? How can we turn Generation Y’s work attitude into something beneficial?</p><p>To cater to their demand for meaningful work, tie anything that needs to be done to revenue. Coach them to set high personal development goals and track these at review time. Have prospective young employees define “meaningful”. If that does not align with what your company’s business is, they may not be a good hire. Alternatively, people being hired for non-revenue positions may very well be motivated by your company's participation in community outreach programs.</p><p>The pack mentality of Gen-Y is well suited for collaborative teams, and makes them uniquely prepared for Agile work environments. Rather than putting them in single cubicles with a window to an Internet full of distractions, put them in larger rooms with shared table-space. The peer pressure will keep momentum up and distractions down. The collaborative setup will bring out the best in them. The small chunks of work will fit their attention span and the rapid results will cater to their zest for instant gratification.</p><p>The concept of people being in an office 9-5 is bunk. Urban sprawl and associated traffic congestion, rising fuel prices and subsequent public transportation congestion conspire against this ancient rite and make telecommuting more attractive. Bosses who want people in an office at all times do not understand how to measure the value that their staff brings. Either the work gets done at a desired quality level or it doesn’t.</p><p>Generation-Y will be much more open to alternative ways of working and will profess to have a higher set of morals than our contemporaries do. This creates an opportunity for us to groom our future leaders, driven by their own ambitions. So if we let go of our <em>idée fixe</em> of how people are supposed to work and focus on achieving results, we will get full cooperation from our new recruits and just may learn a new trick or two.</p><p>Who knows, you and your executives may like this new-found efficiency and take up a new, Boomer-appropriate hobby. Harley, anyone?</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-91093558320316134362008-10-01T20:45:00.000-07:002009-06-04T20:55:38.101-07:00Spillner - The Eternal Struggle Between Good Enough and Perfect<p>By Kent Spillner - <em>1 October 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEho2p6ffPkotsFYeHxY6j5PXTaBDN5MBkWyO0r3PmKF9l6x6i5CW3polJt-uQYKslhqYh9H0bGV1fH-RXPqRyhKextsYOfH5cHTWD0tdG99EJLUgTyYNenFJ7n-WJWTcoan-OQNulpDB6o/s1600-h/spillner3.JPG"><img id="BLOGGER_PHOTO_ID_5343642693282380002" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEho2p6ffPkotsFYeHxY6j5PXTaBDN5MBkWyO0r3PmKF9l6x6i5CW3polJt-uQYKslhqYh9H0bGV1fH-RXPqRyhKextsYOfH5cHTWD0tdG99EJLUgTyYNenFJ7n-WJWTcoan-OQNulpDB6o/s200/spillner3.JPG" border="0" /></a> <p>Software development projects should not be managed with the assumption that the final product would be perfect if only there weren't budgets or deadlines. Although theoretically true -- given infinite time and effort, the perfect solution would eventually be developed (along with an infinite number of imperfect ones) -- this style of thinking only sets the team and business up for failure. Instead, project teams should focus on delivering a working product today, and a better one tomorrow.</p><p><span style="font-size:85%;"><strong>Perfect Ain't Possible</strong></span></p><p>I applaud the good intentions of teams that plan to build the perfect solution, but that's not a realistic way to work. No amount of planning can account for every contingency (well, short of infinite planning, but then there wouldn't be time to develop anything!) Ditto development. Endlessly cranking out code is not a recipe for perfection. Unfortunately, it's hard to argue against such behavior. That's partly because, again, the assumption is theoretically true, and partly because it's in our nature. When people can visualize a goal, they're able to figure out the necessary steps towards achieving it. That's a very powerful capability. It's also very misleading. It requires tremendous genius to correctly figure out every step required to build something of modest complexity. And it requires even greater will power to backtrack several steps when you start heading down the wrong path.</p><p>The rapid evolution of modern business makes it impossible to correctly figure out every step, often because the goal itself is constantly changing. And the dynamic nature of software makes it especially painful to head down a dead end because developers can push code quite a ways before eventually hitting the wall. Now throw in budgets and deadlines. Not only do teams have to do everything right, they also have to do it on time the first time. Trying to build perfect components that make up a perfect whole is an uphill struggle, even without the business constraints.</p><p><strong><span style="font-size:85%;">Lather, Rinse, Repeat</span></strong></p><p>Instead of pretending to build the perfect system, software development teams should build a good one, then make it better. Not in the next release or the next update, but in the very next build. Continuous improvement, not ultimate perfection, should be the goal. The difference in approach can be staggering. Where teams that strive for perfection end up floundering, teams that focus on continuous improvement end up delivering. The uphill struggle becomes a leisurely stroll. This is not meant to imply that continuous integration is a convenient excuse for laziness or slack. On the contrary, continuous improvement is hard work that requires discipline and dedication, just like striving for perfection does. But whereas achieving perfection is impossible, stepwise monotonic improvements are manageable.</p><p><strong><span style="font-size:85%;">Prologue</span></strong></p><p>When I was an undergraduate, I worked as a programmer at a research lab on campus. It was a formative experience. Super smart people, great work environment, interesting problems. Then we lost our funding. That's when reality sunk in: we weren't as good as we thought. To get our ship back in order, we hired a full-time project manager. Under his guidance, we rewrote two whole research systems from scratch in about nine months. Our experience from the previous systems certainly helped our productivity -- we knew several mistakes not to make again -- but it was his approach to building software more than anything else that made us successful. I've experienced similar situations three more times since then (I'm sure I'll learn eventually). In each case, the deciding factor in the team's turn-around was a dedication to steady improvement. Instead of shooting for the moon, we worried about building better software.</p><p><strong><span style="font-size:85%;">Stop Hitting Yourself</span></strong></p><p>That's what this column is all about. I've been a part of underperforming teams. I've pulled all-nighters to meet deadlines, fixed bugs right up to the start of demos, broken my share of builds, and had my projects cancelled. I've also been a part of alpha IT teams. I've helped put systems into production ahead of schedule and under budget, I've worked on projects that release new versions week after week without any serious bugs, and I've felt the excitement return to the office as teams respond to disaster by building overwhelming success. I want to share with you the lessons I've learned, and help you avoid the mistakes I've made. I want to offer advice borne from my own personal experiences, and help you build successful software.</p><p><strong><span style="font-size:85%;">It's All About the Build</span></strong></p><p>I used to think that the best place to start changing software development teams was at the bottom. Get the developers to write better code and focus more closely on building what the customer wants. Now, I think it's best to go straight for the gold: the build. Builds are the only true measure of success on a software project; they're the only product that delivers value. Hence, my first column <a href="http://alphaitjournal.blogspot.com/2008/07/spillner-big-projects-small-increments.html">on the importance of frequent, regular releases into production</a>.</p><p>Then what? What should you do after delivering new features and functionality in individual increments? Make the product better. You don't have to invest in making it radically better, just better. And make it better with every release. And what then? Your product is improving, let's improve the process, too! I want to help you iterate, and iterate well. I want to help you organize your work, and then I want to help you manage it better. I want to help you engage every member of your team, and I want to help you keep every member engaged. And all the while, I want you to continue pushing out new versions of your software, and I want you to make each better than the last.</p><br /><hr /><br /><p><strong>About Kent Spillner: </strong>Kent loves writing code and delivering working software. He hates cubicles, meetings and Monday mornings.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0tag:blogger.com,1999:blog-123318888665066571.post-862849757968388362008-09-24T20:40:00.000-07:002009-06-04T20:44:40.527-07:00Robarts/Rickmeier - How Deep Should Your Pockets Be?<p>By Jane Robarts and Mark Rickmeier - <em>24 September 2008</em></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWBfecs2uheRy-eM2WDqyD3MhctWuHVSLHVX4jH-ICqyW6dYiCiq05xcXf4Nh4-13ADdaztER-1UAPX41DZwKgMS6YZF3kbHsTyfsbcS9p5SuM1GJPM_4JXq1I6gLXkUnWauw1KZo5aHI/s1600-h/robarts1.JPG"><img id="BLOGGER_PHOTO_ID_5343649311065049154" style="FLOAT: left; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWBfecs2uheRy-eM2WDqyD3MhctWuHVSLHVX4jH-ICqyW6dYiCiq05xcXf4Nh4-13ADdaztER-1UAPX41DZwKgMS6YZF3kbHsTyfsbcS9p5SuM1GJPM_4JXq1I6gLXkUnWauw1KZo5aHI/s200/robarts1.JPG" border="0" /></a> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5KZmoauQaWk_yCkpkgLtWuOkBPhF1Aszh4tK3qCPrx1sJHc3WVht_XYX1OcclNLDct8vm_vSUzOn8qpzaEv0uJ67oDt3RmprodFgxXT-uZmu3vvc78JZNyDmPklL5mfO1bj2DzWIm8sw/s1600-h/rickmeier2.JPG"><img id="BLOGGER_PHOTO_ID_5343649209216055042" style="FLOAT: left; WIDTH: 60px; CURSOR: hand; HEIGHT: 74px" alt="" hspace="6" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5KZmoauQaWk_yCkpkgLtWuOkBPhF1Aszh4tK3qCPrx1sJHc3WVht_XYX1OcclNLDct8vm_vSUzOn8qpzaEv0uJ67oDt3RmprodFgxXT-uZmu3vvc78JZNyDmPklL5mfO1bj2DzWIm8sw/s200/rickmeier2.JPG" border="0" /></a>Teams and organizations usually choose to distribute an Agile project across multiple locations for one of two reasons: cost savings or location of resources. In the latter case, organizations often have no choice but to distribute a project due to the location of delivery team members or subject matter experts, or the availability of office space. Cost savings, however, are another matter entirely. Many organizations are choosing to distribute projects overseas to development shops in Asia. Wooed by the reduced costs overseas development can offer through lower salaries and expenses, organizations often leap into distributed development expecting a margin equal to the difference in salaries of the employees. <p>Distributed delivery, especially captive offshore or outsourced overseas delivery, has additional costs often not considered. Identifying and quantifying these costs before deciding to distribute can be the difference between a well-budgeted and planned project and one that continuously leaks money and time.</p><p>On the surface, it may seem simple to forecast the extra costs associated with distributed delivery: budget a few trips to transition knowledge at the start and end of the project, ensure the teams all have phone lines to communicate, and recognize that people may have to adjust their schedules a bit due to time zone challenges. However, as one digs deeper, it becomes clear that there additional prices to be paid to successfully distribute a project.</p><p>Take, for example, the costs associated with travel to and from the distributed sites. An organization has undertaken a distributed project and is sending a subject matter expert (SME) to the offshore location to transfer knowledge early in the project. Flights to and from the site have been priced and accommodations budgeted. On the surface, all seems planned out. It turns out this employee needs a visa to travel. But first he needs a passport. So the organization digs into its pockets, pays for the passport and visa, and absorbs the cost of the SME having to spend two days queueing at the passport office and consulate. Now, the SME is ready to travel. Almost. There are the immunizations to be taken care of. Digging further into the organization’s pockets, immunizations are paid for and a further half day is taken off to visit the doctor.</p><p>Costs continue to mount once the SME realizes that he’ll need a computer while at the offshore site. His company-issued desktop can’t travel with him. Yet again, the pockets open up and a laptop is procured. A day of the SME’s time is spent configuring this computer for his needs.</p><p>Finally, our SME starts his voyage offshore. It’s a 36-hour trip overseas to the offshore facility. He’s travelling during the week, and the organization reaches a little further into its pockets as the SME is unavailable during this time to answer questions and productivity of the development team slows down. Despite the SME arriving at the offshore site a bit jetlagged, the visit is a huge success. Knowledge is transferred to the offshore team, rapport is built, and only once does the organization have to dig into its pockets unexpectedly when the SME realizes his cell phone won’t work overseas.</p><p>These small costs, while individually insignificant, accumulate to become a big expenditure for the organization, not only in terms of cash but also in terms of loss of the SME’s valuable time and the compounding impact this has across the team.</p><p>Beyond travel, there are other costs of distributed delivery. All projects plan a certain amount of contingency. Distributed projects need to plan for more. Events at one site can have a ripple effect on the other. A snowstorm at one site may mean half the team is out, creating a bottleneck to the other team. A power outage on the offshore side may mean developers onshore can’t get the latest code. These two independent events can have double the impact, requiring the organization to reach into its pockets to pay for the loss of productivity.</p><p>Employee loyalty is expensive. Distributed delivery, especially where it involves extreme time zone changes, can take a toll on an employee. This ‘flat world’ of software delivery still has activity regulated by daylight and normal operating hours. Distributed delivery teams have to work outside of these normal hours to collaborate with their distanced team members. It’s not uncommon for distributed teams to be burdened with early morning and late evening phone calls, emails, or video conferences. People tire. Social lives suffer. And employee loyalty is challenged. Compensating for this with perks such as extra paid leave, in-office meals, and even late-night cab rides home all add to the cost of a distributed project.</p><p>Adding up all the factors for this distributed project, the organization’s pockets had better go deeper than simply the cost of resources and travel. The little items add up and often compound, and the embedded costs escalate. Planning for all of these costs prior to embarking on a distributed project will guarantee that the true cost advantages to distributing are realized.</p><p>All of this makes distributed Agile delivery sound like an expensive venture not worth pursuing. This isn't necessarily true: cost benefits can definitely be realized. There is a point where the investment becomes worthwhile. It's just important to understand and factor in all those hidden costs when budgeting for distributed delivery. This is particularly true with distributed Agile delivery which expects changing requirements, relies on a solid business understanding by the team, and expects designs to evolve.</p><p>At what point does the investment in distributed delivery make sense? There is no set rule, no formula that can be applied. Having the right economy of scale to justify the cost of distributed development is critical to reaping the benefits of lower salaries, 24-hour development cycles, and available resources. The simple rule is: <em>don't be blinded by the lower burn rates offered by offshore development.</em> Be prepared to do the homework and fully understand the hidden costs of distributed development:</p><ul><li>infrastructure and hardware, and more complex (and time-consuming) procurement rules for each</li><li>travel costs, especially last-minute emergency trips</li><li>cross pollination: transferring team members from each location to work for long periods with teams in other locations de-risks a project, but isn't done in zero time or for zero cost</li><li>additional roles: duplication of roles in each location may be necessary to ensure the right individuals are available to answer questions, guide the team, etc.</li><li>latency in communication: at best, work is delayed because somebody isn't instantly available; at worst, work proceeds and leads to a false positive that work is complete and requires rework to correct what was done</li><li>additional contingency to reflect the exponential loss of capacity when key people are unavailable or where events in one location impact progress in another</li><li>long distance calls, communication devices, video recorders, digital cameras, international mobile phone roaming, etc.</li><li>personal strain of communicating (or not communiating) via lo-fi channels that leads to frustration, hostility and even withdrawal</li><li>changes in personal schedules to account for timezones</li><li>learning the rules and procedures - all countries have different visa requirements</li></ul><p>Longer-running Agile projects composed of multiple releases typically see the cost savings to a greater extent than short-term ones. Many of the additional costs for distributed development are one-off or early-stage events in the life of a project. Hardware investments typically occur only once. If there is a stable distributed team, knowledge transfer visits and rotations may decrease over the lifetime of the project. As Agile practices mature for the distributed team and they find their pace and understand the business, communication needs between the locations may diminish. The longer an Agile team works together on a project, the better able it will absorb startup costs and more likely it is to become efficient in work patterns, yielding the expected benefits of distributing work.</p><p>Distributed Agile delivery in most cases is a worthwhile undertaking. The benefits may not be realized as early as you might anticipate, and the costs may be higher, so your pockets may have to be deeper than initially thought. However, careful and considered planning and budgeting early on will help predict if the project is worth the distributed investment.</p><p></p><br /><hr /><br /><p><strong>About Jane Robarts: </strong>Jane has over 10 years of experience in custom development of enterprise applications as a developer, analyst, project manager, and coach. She has consulted on and managed projects in India, China, the UK, the US, Australia and Canada. Jane has spent most of the last several years coaching distributed teams and working directly on distributed Agile delivery projects both onshore and offshore. She has also developed and delivered many sessions on Agile delivery to a variety of audiences.</p><p><strong>About Mark Rickmeier: </strong>Mark has 8 years' experience as a quality assurance tester, business analyst, iteration manager, Scrum master and project manager working on large scale enterprise applications. He has extensive distributed development experience working with project teams in Australia, India, China, Canada, the UK, and the US. His industry background includes equipment leasing, retail, insurance, healthcare and retail banking. He is currently a project manager specializing in Agile transformation and project governance with a focus on metrics and measurement.</p>Ross Pettithttp://www.blogger.com/profile/15010068376528802078noreply@blogger.com0