Transparency is the Track to Trust


Recently, as I sat on the Northeast corridor train, the ticket-taker informed us that we would be delayed 15 minutes. As I thought about the impact on my day, a flutter of activity rippled through the cabin. Passengers called bosses, colleagues, wives and customers spreading the news. What was interesting was that the relayed news was different: some people doubled the time, others bumped it up to solid hour and, shockingly, no one made it shorter.

As a software project manager, I have had this reaction often. Whenever I received an estimate, I instinctively doubled it. However, as the product manager, I was in a position to drill down and get more insight into the origin of the estimate. Was it a WAG (Wild A** Guess) or was it thought out? What assumptions were used? What could I do to make it shorter? The estimate grew as I dug in, but so did the work. The conversation surfaced issues that needed to be discussed and brought clarity to the task at hand.

Downbound Train

Now, as a regular passenger spending my money with NJ Transit, I felt compelled to "dig in" and see if I could help or understand the situation better. Was that estimate from the conductor or Penn Station? Why were we delayed? Is it a signal, power line or derailment? Any insight would help me determine the accuracy or credibility of the estimate, but that sort of interaction goes against social roles -- and these days may even be a Federal offense!

In truth, I don't want to be a railway project manager -- but I do want transparency. And I believe that transparency is the primary source of stress in software development. How many times have you been under the gun trying to explain why certain features take longer than others? Or why a performance is so slow? Or why you are still looking for the cause of that bug -- armed with nothing more than soundbites from your development team, when what you really needed was facts.

Getting On Track

Customer (internal and external) expectations are dragging development into greater and greater maturity. The great thing is that tools and processes are finally mature enough to support this industrialization of software engineering. Today’s processes are standardized, consistent and self-correcting, and tools are available that provide fact-based measurement and insight into these processes and the systems they develop.

The largest opportunity for improving quality and productivity during application development is in eliminating its largest sources of waste: defects and the rework they cause. In many organizations, 30% to 50% of the development effort is devoted to rework. These staggering numbers are driven by the fact that defects become 10 times more expensive to fix for each major phase of the software life cycle they slip past. Under these circumstances, quality largely determines productivity. However, by applying lean principles of static analysis to application development, companies can realize significant overall cost and risk reduction - 10% or more - most of which is based solely on waste elimination and driving desired behavior among AD teams.

Keeping application development on track comes down to finding the best visibility over your software, because, in the end, productivity without quality is a waste, quality without productivity is costly and optimal performance is achieved only when both quality and productivity are on the same track.

  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Pete Pizzutillo
Pete Pizzutillo Vice President
Pete Pizzutillo is Vice President at CAST and has spent the last 15 years working in the software industry. He passionately believes Software Intelligence is the cornerstone to successful digital transformation, and he actively helps customers realize the benefits of CAST's software analytics to ensure their IT systems are secure, resilient and efficient to support the next wave of modern business.
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item