Yes, Size Matters
October 1, 2012
Some time ago I released this paper on the challenges of sizing a software project. Recently I was asked about this relative to Agile Stories and Story Points. I realized it would be a good post for our blog. Enjoy!
Frequently Asked Questions (FAQs) on “Software Size”
Software is everywhere in modern life – from automobiles, airplanes, utilities, banks, to complex systems and global communications networks. They span from tiny applets that may comprise just a handful of instructions – to giant systems running millions of lines of code that took years to build.
Software professionals are at the front lines of this information revolution. The following are Frequently Asked Questions about how to measure the size of software applications. We hope this is useful to help software professionals better describe their work to stakeholders in their organization, and to reliably estimate new projects as software continues to grow in importance to our companies and to our daily lives.
Question: What do we mean by the term, “Software Size”
Answer: For starters, think of T-shirts – Small, Medium, Large, or Extra-Large, or houses that can range from a small summer cottage all the way up to a 20,000 sq ft Hollywood mansion on a sprawling estate.
So it goes with software. You can have a small program with a few cool features, or a huge, complex computerized trading system for the New York Stock Exchange comprised of millions of lines of code, and everything in-between.
Question: I have a large project and its size is 20 people. Is that what you mean?
Answer: Not quite. That’s actually the number of the people on your team, or number of staff resources on the project. It’s not the amount of functionality, or the volume of software created by a team of that size.
Question: Ok, so you’re saying that small feature sets for a software program – or a long list of features – is what you mean by the size of the software. Do you also mean lines of code?
Answer: That’s another way to look at it. Generally speaking, to complete a project that satisfies hundreds of requirements or feature requests takes a lot more working code than a tiny applet with five simple features. We talk about things like “Units of Need” which describe the software capabilities that customers want from that perspective. This includes a count of features or requirements, which is also addressed by Function Points. In the Agile realm, the vocabulary of choice for features includes User Stories and Story Points.
We think of “Units of Work” to describe what software developers and programmers produce to satisfy those features. This includes technical requirements, design elements, and specification requirements. From there, developers create programs, objects, and subroutines – or software code that’s written in a particular programming language. Computers run software programs – not feature lists. This working code is what developers – with their artful designs and technical prowess – design, code, and test.
Ideally, we want simple designs that are clean and elegant. Simple designs, where possible, are often produced faster with less effort. They also tend to be more reliable and easier to maintain. The converse is a sloppy design with lots of “spaghetti code” that’s buggy, requires more rework and longer testing. This often takes more time and costs more, in the long run.
Question: If what you’re saying is true, wouldn’t you expect it to take less code to produce a feature, or as they say in Agile terminology, a User Story?
Answer: Exactly! Less code takes less time, requires fewer effort hours to build and test, and tends to be more reliable. That means you don’t have to test as much, and you can finish sooner – hence you’re more productive.
Also, to understand these relationships – how much code it takes to produce a Function Point, a feature, or a User Story, can be very valuable. It’s like a currency conversion from dollars to euros or changing units from miles to kilometers. If you have a good handle on this conversion, which at QSM we call “Gearing Factors,” you can move from one realm to another fairly easily. Early on in a project, if you think you have to build 40 to 50 features, you can come up with an assessment of the amount of software that might be required.
Question: Should we count using Function Points? I heard that this was an industry standard.
Answer: It depends on whether this metric is an appropriate fit for what you do. In the 1980s, Alan Albrecht at IBM defined Function Points to describe the predominant architecture for systems of that era, known as CRUD – Create, Read, Update, Delete – against an underlying database. That’s what IBM mainframe batch processes mostly performed.
If that’s a fundamental architecture for what you build today, then describing Units of Need in that vocabulary can work. Ultimately, to create working software that delivers a certain number of Function Points requires code, which can also be counted. (Counting Function Points is a laborious manual process. Code counts can be automated with a tool.)
On the other hand, you might build software that flies airplanes, runs under a distributed architecture, has wireless features, online error checking and diagnostics, or something in the modern world that’s a long way from a CRUD architecture on a mainframe. In that case, Function Points might not be an easy fit. To count Function Points, you also need a well-written requirements specification that’s not outdated. Unfortunately, many organizations don’t have that.
As we move more toward Agile methods, many teams prefer to describe features as User Stories – with each being described on a complexity scale known as Story Points. These are also ultimately produced through working code. If you find yourself in this world, that might be a better fit.