Software Analytics, un estímulo para el éxito de negocio

Con motivo de nuestro 25 aniversario, el pasado 16 de junio tuvo lugar el primer User Workshop a nivel local, una sesión cuyo objetivo reside en crear una comunidad de usuarios de CAST AIP y mantener informados a los clientes de las novedades de nuestras soluciones.
¿Hacia dónde evolucionan las soluciones de CAST y cómo pueden influir en las organizaciones?, ¿Estoy optimizando el uso de CAST AIP en mi organización? En formato taller y para crear un ambiente dinámico y participativo se dio respuesta a esta y muchas otras inquietudes y experiencias de un grupo de usuarios de CAST AIP con el objetivo de extraer todo el valor y potencial que la herramienta puede aportar en cada organización y dependiendo del público al que se dirijan los resultados de análisis extraído.

Key Discussion Points from Forrester Webinar: Agile Portfolio Management Requires Rapid Transparency

Application portfolio analysis was at the center of discussion as Forrester Research Vice President and Principal Analyst, Margo Visitacion, presented how Agile development is affecting the application development process and IT’s portfolio planning. Ms. Visitacion explained that in the “Age of the customer,” they want more for less and expect companies to fluidly change based on their needs and demands. As companies shift their attention to customers’ experiences rather than production figures, it’s leading directly to higher revenue and a longer-lasting relationships.
So how do organizations remain agile to customer needs? They employ an Agile portfolio management process that collects metrics while aligning with the budgeting process; understanding that requirements will change. Using this strategy, companies gain clear visibility into their portfolio to measure risk, cost and complexity based upon objective measurements. The data collected during development enables them to defend current positioning and communicate more effectively with the business.
Here are some recent thought provoking questions, along with supporting answers, which we received during the Forrester webinar:

Software Risk: Executive Insights on Application Resiliency


Software risks to the business, specifically Application Resiliency, headline a recent executive roundtable hosted by CAST and sponsored by IBM Italy, ZeroUno and the Boston Consulting Group.  European IT executives from the financial services industry assembled to debate the importance of mitigating software risks to their business.

Five Reasons You MUST Measure Software Complexity

There’s an old adage in the IT industry – you can’t manage what you can’t measure. Knowing how complex an organization’s application portfolio is provides insight into how to manage it best. The problem is the issues that comprise software complexity – legacy system remnants, antiquated code, overwritten and rewritten code, the integration of formerly proprietary applications, et al – are the same things that make measuring it difficult.
With multiple system interfaces and complex requirements, the complexity of software systems sometimes grows beyond control, rendering applications and portfolios too costly to maintain and too risky to enhance. Left unchecked, software complexity can run rampant in delivered projects, leaving behind bloated, cumbersome applications. In fact, Alain April, an expert in the field of IT maintenance, has stated, “the act of maintaining software necessarily degrades it.”

What the New York Giants Can Teach Us about Software Quality

As we all know, Sundays are for football, and this past Sunday brought some choice matchups. Although I am a devout fan of the New England Patriots, one of my favorite games paired the undefeated Green Bay Packers, led by quarterback Aaron Rodgers, and Eli Manning’s New York Giants. Tied with less than two minutes to go in regulation, Rodgers did his best Tom Brady imitation, leading his team on a spectacularly engineered drive that preserved their as-yet unblemished record.
After the game, I wondered if Giants Head Coach Tom Coughlin repeated his prior week’s answer to reporter’s question, where he stated that his staff had prepared the team, but the team hadn’t delivered. It also made me think more about technical debt and the question I posed (and hopefully answered) last month: “Is there a technical tipping point?
Then, I read Gartner analyst David Norton’s post on technical debt, where he quotes his colleague Andy Kyte as predicting technical debt will top $1 trillion within the next five years. Norton states, “that’s a trillion dollars of development that needs to be done to remove bad code, poor architecture, and ill-thought-out technical strategy or simply time catching up with good design.”
As I dug into this more, I came across an excellent presentation from Thomas Sundberg of Sigma Software, which he presented at the Agile Sweden 2009 conference. While it’s two years old, it really got “into the weeds” about the causes and results of as well as potential solutions for technical debt. I thought it would be worthwhile to share a few of his key points here.
Line of Scrimmage: The Causes of Technical Debt
With increasing turnover of IT teams and outsourcing software development, it’s critical that developers are educated in the domain and that there’s a process in place to retain information. In many organizations, each time there’s a staffing change, knowledge is lost. Sundberg asks, “if you don’t understand the problem you need to solve, how can you solve it?”
He adds that given an environment of continuously changing talent, teams should always verify their assumptions and these should be stated as clearly as possible as part of the planning and ongoing communications process. “Incorrect assumptions are the mother of all f**k ups,” he notes.
Another contributor to additional technical debt is premature optimization. Premature optimization can cause developers to optimize the wrong feature, resulting in code that isn’t used, an incorrect solution or a solution with unnecessary complexity – all a waste of time and resources.
The Game Plan: Dealing with Technical Debt
Sundberg offered a host of ideas to reduce technical debt. I realize several of these are elementary, but in the bustle of meeting everyday objectives, several of these practices can easily fall by the wayside.
Team communication is critical, especially when development is spread out between in-house and outsourced talent.  Managers must identify team rules and stick with them, discuss the pros and cons to each solution and then choose one approach and stick to it as long as it makes sense. This may sound easy, but when developers create their own rules and generate different solutions to similar problems, they waste time and resources.
Sundberg notes that when teams fall into technical debt, they should plan immediately for how that debt will be repaid, but the debt doesn’t have to be repaid immediately. He pushes for teams to have a plan that pays it down at a sustainable pace, but is adamant about identifying the debt and creating a roadmap for paying it off.
Managers should consider paired programming to avoid the knowledge drain that occurs when staffing changes.  This approach can result in better code development, including knowledge and experience on a given task from two developers versus one, while also ensuring that institutional knowledge stays within the organization.
Managers should think about test-driven development (TDD), which encourages developers to solve a problem twice, and then work with the optimal of the two solutions.  Sundberg notes this can result in at least the doubling of code quality.
Sundberg continues that living with small errors will eventually lead developers to accept larger ones, building in technical debt in the process. The first time a developer says, “I’ll fix that later,” he/she is creating new technical debt.
Ensuring there’s discipline in the refactoring process will help wring out technical debt as well. Sundberg encourages developers to run all tests, seek out the simplest solutions to fix problems, then run all tests again and only when all tests pass should developers run checkin. Sticking with this approach will decrease technical debt.
The Goal Line: Solutions for Technical Debt
Sundberg notes a five-step method to reduce technical debt:

Change the working environment, since technical problems are often symptoms of process programs
Continuously strive for greater knowledge
Refactor relentlessly
Visualize technical debt as specific tasks to address to help the process of reducing it
Automate testing, having computers test everything as often as possible.

Finally, Sundberg concludes by commenting that you pay down technical debt the same way you eat an elephant – one bite at a time. Such simple ideas could spell the winning formula for reaching state of reduced reduced technical debt and optimal structural application quality – the “Super Bowl of Software.”

Gold Stars are Only for Winners

With the ever-growing abundance of viruses, malware and other threats to our networks, laptops, mobile and other devices, I was interested to read Peter Saddington’s blog post for @agilescout that brings a software development angle to Todd Dewett’s post, “Soccer Has Ruined America.”
Although just a casual fan of the game the rest of the world calls “football” (football to me is still the game played by Tom Brady and my beloved New England Patriots), I can’t say I completely agree with the headline of the post; nevertheless, at the urging of a colleague who is a soccer mom and blogger, I decided to dive in.
Dewett’s premise revolves around the idea that addressing our current malaise has nothing to do with stimulus spending or reducing the size of government, but with the elimination of youth soccer in America!
He points out that a generation of Americans has grown up with the idea that we deserve a trophy just for showing up. Every kid on the soccer team gets a trophy, whether the team won or lost, whether he/she was a leading scorer or spent the season fetching water; this along with the “no scoring” youth sports leagues are two of my greatest pet peeves about youth sports. In the business setting, Dewett appropriately equates the willy-nilly trophy-giving with how employees today receive good conduct certificates just for arriving at work on time 30 days straight. Should I start expecting rewards for making the coffee in the morning, getting my daughter to the bus stop or making sure the dishes are done each night?
Second Place is First Loser
And so it goes with much of today’s software. Developers are rewarded for completing the project, but as for the quality of the code, it’s all too often left to the user to find flaws and notify the developer, who then fixes them…or not. My recent post on Microsoft’s monthly Patch Tuesdays serves as the most flagrant example.
I’m with Todd when it comes to how we treat people, but I want to take him one step further. Managers must create a workplace that maximizes the opportunities for success. This includes creating a civil, collegial and supportive work atmosphere. It includes assessing people’s skill sets and creating opportunities to take advantage of strengths, while offering training and other solutions to address weaknesses. But it also includes the ability to recognize when a person isn’t right for a position and if possible re-crafting either that position or another to enable that employee to thrive rather than just jettisoning the individual.
With that atmosphere in place, if a developer doesn’t succeed, to paraphrase Herman Cain, “it’s your fault!”
Reach for the Stars
For software developers, the only “gold stars” should be for flawless code. Happily, today’s new generation of software analysis solutions arms development teams with the ability to analyze how the developer assembled the code, its performance, security and technical sophistication.  With this information, teams can take previously qualitative assessments of a developer’s capabilities – namely if the code is written according to best practices for that programming language or is it likely to have high/low long-term cost of maintenance – and turn them into a quantitative measurement.
Developers receive immediate input into the quality of their work and can adjust their work on the fly versus completing a project and then undertaking extensive rewriting and refactoring.
Whether evaluating in-house or outsourced software development, today’s static structural analysis of software replaces qualitative observation with quantitative metrics.  IT and development teams can identify specific outcomes and quality standards to application software that they can apply across the board.
In addition to identifying high performance, structural analysis can demonstrate performance weaknesses and the need for skills improvements.  Because IT budgets remain tight, managers gain the information they need to focus specific training curricula to address specific deficiencies.
In today’s resource-constrained work environments, many companies can’t afford to give everyone a trophy just for showing up, but that’s a good thing. It forces businesses to employ some measure of structural assessment – such as automated analysis and measurement – so managers can evaluate the quality and volume of code that’s developed, provide rewards and incentives for talented programmers and offer remedial assistance to those who require assistance.
And as the economy improves and budgets loosen, separating the leading scorers from the water carriers will position both internal and outsourced programming teams to compete effectively as new opportunities arise. For those companies that have measured developers’ performances through structural analysis, their trophies will be in the form of optimal application software quality, increased innovation and reduced technical debt.

Curtis Gives Keynote on Technical Debt at Construx

The Construx Software Executive Summit, which opens today in Seattle, WA, provides a forum for top executives to compare, evaluate and improve their Software Development experiences and strategies at the enterprise level. Keynoting this year’s summit will be CAST’s chief scientist, Dr. Bill Curtis, who will present on the topic, “How Governing Code Quality Reduces Business Cost and Risk.”
Curtis’ keynote will focus on how addressing structural quality of application software during pre-production mitigates, and in many cases eliminates, the risk of software malfunctions and outages after deployment, which also significantly reduces a company’s technical debt. He will explain how companies can work with legacy systems to achieve optimal structural quality of application software and thereby reduce their technical debt.
In addition to Curtis, other IT industry notables presenting at Construx include: Steve McConnell, Tom Gilb, James Whittaker, Philippe Kruchten and Ward Cunningham.
Curtis is an industry luminary who is responsible for influencing CAST’s scientific and strategic direction, as well as helping CAST educate the IT market about the importance of managing and measuring the quality of its software. He is best known for leading development of the Capability Maturity Model (CMM), which has become the global standard for evaluating the capability of software development organizations.
Recently elected a Fellow of the Institute of Electrical and Electronics Engineers for his contributions to software process improvement and measurement, Curtis is the director and co-founder of CISQ, an IT industry leadership group comprised of IT executives from the Global 2000, system integrators, outsourced service providers and software technology vendors all of whom are committed to introducing a computable metrics standard for measuring software quality.