In software, bigger is not better

For most things, bigger is better. Hamburgers, cars, bank accounts... generally everything is better when it is bigger. But not for software. Software is not necessarily better when it is bigger.

By "big", I don't mean "popular". I mean "lines of code".

Software runs on a platform. (We used to call it an "operating system", and in the Eldar Days, software ran on hardware.)

Platforms change. Over time, they evolve. Windows XP becomes Windows Vista, and then Windows 7. (And now, Windows 8.) Linux changes from kernel 2.2 to kernel 2.4, and then 2.6. The popular Linux windows manager changes from KDE to Gnome. The Java JVM changes from version 1.5 to 1.6, and then to 1.7. Popular languages change from FORTRAN to BASIC, from BASIC to C, from C to C++, and from C++ to Java (or from Perl to Python to Ruby).

A software solution -- something that meets a need of the business -- must live on these platforms. And since it lives for a significant period of time, it must move from one platform to another as platforms change.

We tend to think that a software solution, once written, tested, and deployed, is permanent. That is, we think the "soft" solution is "firm" or even "hard". But we're wrong. It's still soft -- and often fragile.

For software to endure it must evolve with the platforms. For it to evolve, it must change. For it to change, someone must be capable of modifying the existing code and mutating it into something new. Some changes are small (Java 1.5 to Java 1.6), and some changes are large (Visual Basic 6 to VB.NET).

To change software, one must understand it. One must know the source code and understand the effects of changes to the code.

Which brings us back to the size of the source code.

The larger the source code, the harder it is to understand.

To be fair, there are many factors that affect our ability to understand source code. The language, our knowledge of the problem domain, and the style and readability of the code all affect our ability to make changes. (Also, the presence of automated tests makes for easier maintenance, since it assures us that changes affect only those features that we want to change.)

Yet size matters. Large systems are difficult to port to new platforms, especially platforms that are significantly different than the previous platform. (Say, moving from Windows C++/SDK/MFC to Java/Swing/Struts.)

For an enduring system, we must not assume that the platform will endure. (Microsoft's Windows 8 is a good example.) For enduring systems, we must design applications that can move from one platform to another. A tricky proposition, since the "new" platform will probably not exist when we construct the application.

I expect that a large number of Windows applications will not move to the new platforms of Java, Android, iPhone, or even Windows 8. (The legacy "desktop" mode of Windows 8 does not count.) They will not move because they are too large, too complicated, and too opaque to migrate to newer platforms. Instead, organizations will re-write applications for the new platforms.

But re-writing takes time. It takes more time for larger applications than for smaller applications. And there is always the risk that some feature will be omitted or implemented improperly.

Bigger is not always better. Bigger, when it comes to software, entails risks. The wise product manager will be aware of the risks and plan for them.