• Prev
  • Next

Plus ça change, plus c’est la mȇme chose

DCG 1994 Logo 2C

This is the fifth and final post in a series that offers our management team's reflections on DCG's 20th anniversary and the state of the software industry. Previous posts herehere,here, and here.

I make no excuse for using a French expression, as it sums up things very succinctly. “The more things change, the more they stay the same” is something of a cliché, and of course it’s not completely true, but then again, it’s not completely false.

This year is DCG/DCG-SMS’ 20th anniversary. In thinking about how the industry has changed in the past 20 years, there’s no better way to describe it than the above expression.

The Need For Change

Who remembers SSADM –Structured Systems Analysis and Design Method? Developed by CCTA, who also developed ITIL, SSADM was (and is) a very structured 7-step waterfall process from Stage 0 – Feasibility to Stage 6 – Physical Design; oh, and then you had to build the application. SSADM is the culmination of the Big Process approach to application development; if all went to according to the huge WBS and GANTT chart plan, then you had a perfect system out of the sausage machine.  

It didn’t work, of course. The problem with any process-heavy approach is that the base assumption is that the world stands still while you build the application. We all know that, even with small application builds, a lot of things change our view of the business needs while we’re working.  SSADM was aimed at those government projects that would end up in the top one percent of the size range (5,000+ Function Points – FP), where change during the project is so huge that you can never get to the end point and “analysis paralysis” sets in.

Clearly there was a problem. One project I was on as a requirements manager delivered its first release at 0.5 FP/100 hrs, against industry expectations of about 6 FP/100 hrs. By the end, we were still only producing 1.5 FP/100 hrs and the application was nearly 8,000 FP. You do the math (at £400 per day base cost). The project team was huge and we were all working our socks off. We did deliver, of course, but with a lot of help from EDS, who became outsourcing partners during the project.

So now we have Agile. Large programmes are delivered through smaller applications, built incrementally by small teams, using continuous integration to deliver change quickly and much more effectively. There is process, of course, exemplified by SAFe and DSDM. to provide programme level support for scrum and the development methods at its heart.

In those organisations that become Agile throughout, a software development methodology has become a method for delivering business change. Hooray, the cavalry has come over the horizon and saved the day. Or has it?

Things Stay the Same

So now we’ve moved on. We do things so much better, but still projects fail. The 2014 PMI Pulse report shows that projects include IT waste totaling $109m of every $1bn spent. Highly Agile organisations are better at delivery, and crucially, such organisations tend to be more mature at change management, project management, and have active PMOs. They also have more visible and active project sponsors.

Sadly, in those organisations where effective agility has not been adopted, chaos reigns. Too often we hear the comment, “You don’t understand; we’re Agile, so we don’t need all that process.” Haven’t they heard of minimum marketable features? Where sponsors and teams have no idea of where their business is going, Agile becomes a mask for failure of strategy, and dreams and money get poured down the drain.

So what remains the same is that discipline, foresight, and adherence to Agile processes are key to successful delivery.  People and organisations who were poor at applying waterfall principles tend to be poor at Agile too.

Agile is a disruptive game changer; it can and does increase the rate of delivery while reducing costs, but treating it as a carte blanche for anarchy does the concepts behind it, and the businesses hoping to reap the benefits, no favours.

Alan Cameron
DCG-SMS, Managing Director

Written by Alan Cameron at 05:00

Tom Cagley Reflects on DCG’s 20th Anniversary

DCG 1994 Logo 2C

This is the fourth post in a series that will offer our management team's reflections on DCG's 20th anniversary and the state of the software industry. Previous posts herehere and here.

 In the world of software development, software enhancement and software maintenance, only one adage has remained true for the past twenty years. Simply put, “If you are currently doing work the same way you were last year, you are out of date.” Processes, techniques, methods and even languages are in a continuous state of change. In order for anyone involved in this industry to stay relevant, they need to continually learn, adapt and adopt the new techniques that deliver value (and not all of them do).

 Of course, change in software development is not as simple as flipping over an etch-a-sketch, shaking and starting again. Each successive wave of change, regardless of the speed at which it happens, leaves at least a little of its essence behind for the next wave to build upon. Examples abound; consider the pedigree of the lean/Agile movement, which can be traced to the design pattern movement in the 90’s, to the continuous process improvement and quality movements of the 80’s, to the works of Dr. Deming and beyond. Just as volcanos build islands, waves of change within software development build on each other. 

 In addition to “change as a constant,” a few other core software principles have not changed: 

  • Software development is an important enabler for most organizations. Software is everywhere, used in almost every job imaginable. Even my local garbage collector uses software automation on its trucks.
  • Software development needs to be managed as a profit or cost center. Pick one, although unless you are selling your software, it will tend to be the latter. Regardless of which you choose, the impact on the corporate bottom line requires IT (in general) and software development (specifically) to be managed as a business.
  • Software development is a mixture of engineering and art. The culture war between the engineering camp and the craftsperson camp has not totally died out; however, mature software development organizations have found a way to merge both points of view. Frameworks such as Agile are a reflection of the two camps blending together . . . albeit noisily.
  • Software development can and should be measured. Whether you use IFPUG or COSMIC function points, SNAP (non-functional size) or you count stories, the techniques that exist to measure productivity, velocity and delivery rate should be used. The questions of “When can I have that project?,” “How much will it cost?” and/or “What will I get?” are not going away. Whether you are a parametric estimator or you adhere to the #NoEstimates thought processes, you need to measure something.
  • Software development is a people business. The raw material of software development (at least currently) is human thought. Without IT professionals and end users that feel they are appreciated and belong, very little good software is delivered.

 So, what will software development be like in 20 years? Will these trends persist? Humans are notoriously poor predictors of the future. What can be said with certainty about how we develop, enhance and support software-centric projects is that the way we work today will not be how we work tomorrow. Will techniques like Agile or architectures like cloud be more prominent? They will likely run through a lifecycle to be replaced by a new tool, a new process or a new architecture that will build on the changes delivered. Software does not stay stagnant.

 Where will DCG be in twenty years? The answer is probably very similar to where software development will be. One general observation I can make, as someone that came to DCG from the outside (corporate and consulting) in the relatively recent past, is that everyone at DCG is a voracious learner and has a passion to be involved in the industry. One of the reasons I joined DCG was to be pushed and that has happened. Therefore, if I were to predict the future, I would say that in twenty years we at DCG will be discussing where software development will be in 2054. That said, has anyone seen my COBOL manual and coding sheet?

Tom Cagley
VP of Consulting & Agile Practice Lead

Written by Tom Cagley at 05:00
Categories :

Michael D. Harris On DCG's 20th Anniversary

DCG 1994 Logo 2C

This is the second post in a series that will offer our management team's reflections on DCG's 20th anniversary and the state of the software industry. The first post is located here.

DCG’s 20th anniversary is a cause for celebration and reflection, so I’d like to take an opportunity to reflect a little on the past 20 years. Naturally, being a metrics sort of person, as I think about the past 20 years, I look for yardsticks for comparison. It just happens that I have the perfect one – our youngest child has his 20th birthday this month! I have to say that while twenty years seems like a long time for a company to be in business, it seems like a very short time in the life of our young son.

Of course, I am a relative latecomer on the scene at DCG. David Garmus and David Herron founded the company in 1994 and ran it for the first 12 years. I owe a debt of gratitude to them because I am sure that launching a new business is a lot harder than keeping an existing one moving forward. Of course, I could argue in the context of my son’s life that I have had to deal the “teenage years” of DCG, but both son and company have been a pleasure these past few years. In both cases, I like to think it was because of the time and effort invested in the early years!

So, how is DCG’s world different from 20 years ago? For this, I’m going to use another convenient yardstick – my just-over-19-years of working in the U.S. When I first came to work here, it was on a five month project for MasterCard. I was Deputy Head of the Engineering Dept. at Nene College (now University of Northampton) in the U.K. at the time. The project was good for the college because it brought in much needed cash, and it was good for MasterCard (the project led to the development of credit/debit card standards for chip cards), and, we hoped it would be a good opportunity for the Harris family to see if a couple of years of living in the U.S. might be a practical, as well as exciting, adventure (it still is!). 

Of course, with a particular emphasis on software, 20 years ago I booked my flights and hotels for the trip by phone, not on the web. The family, including my (not-yet-one-year-old) son, stayed at home until the end of the school year, so my wife, our two older girls and I communicated via CompuServe on dial-up modems! Whether or not the internet existed when the Davids started DCG depends on your definition of “existed.”  From my perspective, we certainly were not thinking about using it on a day-to-day basis. Yet, five years later, after two years of working for MasterCard as a consultant and three years as an employee – one of my peers at MasterCard was “Head of ecommerce!" That five years was the first five years of DCG’s existence.

One of the things we notice at DCG is that many of the services we provide are valuable to our clients on an ongoing basis, but when there is something big going on in the industry (the introduction of the internet, the recession, the sequester, server virtualization, the cloud, etc.), it turns heads and attention (and money) from the “blocking and tackling” of improved project management, which is our clients' bread and butter. I can only imagine what it must have been like starting a metrics and process improvement business in the heady days of the dot com boom. Kudos and thanks to the Davids for making a go of it; I hope we carry on for another 20 years!

Mike Harris
DCG President

Written by Michael D. Harris at 05:00
Categories :

David Herron Reflects on the Software Industry

DCG 1994 Logo 2C

This is the first post in a series that will offer our management team's reflections on DCG's 20th anniversary and the state of the software industry.

This year, DCG celebrates its 20 year anniversary – all 20 of which I’ve spent with the company! As such, it is an opportune time to look back on the software industry and reflect on where we have been and where we are today.

Software: A Changing Landscape

Probably everyone would agree that the business of developing and deploying software is in constant flux. New practices, techniques and tools are continuously being introduced to the development environment with varying degrees of success and sustainability – we’ve seen it time and time again over the past 20 years.

These changes are often influenced by the evolving needs of the business. Cost has always been a business driver, but over the past several years companies have become increasingly focused on software quality and speed (time to market) – and how software performance data can be used to drive strategic decisions.

To address this newfound concern, more and more of our clients are turning to a tried and trusted solution: the use of quantitative and qualitative measurement data to govern software development practices and outcomes – one of DCG’s core offerings.

For example, twenty years ago we saw the rise of the outsourcing mega-deal. In hopes of lowering costs, companies looked to offshore sourcing alternatives with third party suppliers. These mega-deal, multi-year outsourcing arrangements required service level agreements and measures to be established in order to monitor and manage risks. What we learned from these early outsourcing initiatives was that they did not always result in the cost savings that had been anticipated. 

Of course, outsourcing is still very much part of the norm in today’s software development environment, but organizations have developed the ability to make better decisions as to which portions of their development and maintenance activities they choose to outsource. Through the use of now accepted industry performance measures, IT departments are deploying quantitative benchmarks and qualitative assessments to help them better understand levels of productivity and quality performance. Using this information, they are better able to evaluate and select potential cost-saving sourcing strategies.

To that end, the use of software sizing techniques, such as Function Point Analysis, have become a key factor in the effective measurement and management of software, as IT departments and C-level management have increasingly required sound, quantitative data that can measure the value contribution of IT.

Of Course, Some Things Remain the Same

But while proven solutions are being used to address newer business concerns, some issues have continued to plague software over the years. The most costly of these issues occur at the frontend of a software development lifecycle, specifically, the lack of proper requirements development, ineffective cost estimating and ignoring the need to properly set customer expectations. 

Issues associated with these shortcomings have long been recognized by most organizations, and yet proven solutions to these problems have been slow in gaining ground. There seems to be a continued reluctance to make the proper investment necessary to correct these issues. One major reason that these frontend issues are not aggressively addressed is that organizations aren’t typically aware of what these frontend issues are costing them on the backend! For example, poorly defined requirements and taking shortcuts to reduce costs and speed up delivery can have a devastating impact on the quality of the software deliverable, resulting in extended maintenance activities and costs.

We routinely have organizations come to us seeking help in addressing these issues. Our solution involves both some of our standard techniques (sizing), as well as newer ones that have developed over the past 20 years (Agile).

From a sizing perspective, we know that a key measure is to determine the size and complexity of the software problem domain. Using that information we are able to help our clients improve requirements clarity, more effectively estimate project costs and ultimately properly set customer expectations. Proving the old adage, “You can’t properly manage what you don’t measure.”

Similar to sizing, Agile practices have been around for the past twenty years. But, it seems like only recently that IT organizations have come to the realization that by using Agile practices and technologies, they can gain the advantage of working more closely with their business partner to establish the prioritized requirements and incrementally deliver value.

Even though these issues described seem to continually plague software, there are solutions – both old and new – that exist to mediate them, if an organization wishes to do so. In this respect, it’s time for software organizations to step out of the past and move into the future.

On the whole, software will never stop evolving. It’s fun – and sometimes necessary – to talk about and play with new tools and techniques that have come about. But on the whole, while the priorities of IT – and the business – may change, it’s always worthwhile to consider how trusted solutions can be of value.

David Herron
Vice President, Software Performance Management

Written by David Herron at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!