Dealing with Growing Software Complexity

by Krishna on October 13, 2009

Ted Neward had a post wondering why we don't see more small-scale applications being built with tools as it used to be in the past with FoxPro.

[…] many people I care about […] made a healthy living off of building “line of business” applications in FoxPro, which Microsoft has now officially shut down. For those who did Office applications, Visual Basic for Applications has now been officially deprecated in favor of VSTO (Visual Studio Tools for Office), a set of libraries that are available for use by any .NET application language, and of course classic Visual Basic itself has been “brought into the fold” by making it a fully-fledged object-oriented language complete with XML literals and LINQ query capabilities.

Which means, if somebody working for a small school district in western Pennsylvania wants to build a simple application for tracking students’ attendance (rather than tracking it on paper anymore), what do they do?

I am in two minds about this. In agreement with Ted, it would be nice to crank out quick business applications using simple tools. In fact, many applications that are built using .NET or Java could be automated using Excel or Access, not to say even a Word document that is put in a shared folder! It is one of the characteristics of human beings that they will spend more money than they need for things that they could have lived without.

The problem, unfortunately, is that people also display the following characteristics:

  • They get new ideas, i.e., when they see what software can do, they want it to do more.
  • They change their mind about how things should work.
  • They are not organized: they need the software to protect them from their own mistakes or provide them more information to help them out.
  • They don’t understand the millions of man hours that have gone into fine-tuning the functionality in sophisticated off-the-shelf products and demand that in their own applications.

This is all apart from external business reasons for application changes. So there is no “simple” application because the moment it is built, people want to change it.

For the developer, there are 2 choices: Walk away after building it, or continue to make changes for the customer. But even in the first chance, there may be a warranty/guarantee period where the developer continues to be involved with the product. And these changes become more and more difficult with the tools that we had in the past.

There are many dimensions where the “simple” tools of the past made it more difficult. Consider deployment — it is infinitely easier to manage deployment on one web server than worry about many different Windows (or DOS!) machines. Consider simplicity — plain JavaScript versus JQuery. Consider separation of concerns in different architectural layers instead of code lying in the different layers, including the “business” layer and triggers.

There are many more tools today to learn, but they make it simpler, not harder, to code. Ted has a point that the standalone developer has to go through several weeks of learning. But if we are talking about college students, those 6 weeks is spread across a few years of study — not a big deal. But even if it is a person making a new career move into programming, there has to be some investment in educating oneself. Otherwise the programmer will end up fielding more and more support calls instead of moving from one project to another.

Also,  it is possible to build smaller applications using a limited set of present-day technologies. If you look at the 5‑week list that Ted put up, it is plausible that a good programmer can write a small application without using or knowing much of them. For example, Joel Spolsky and Co. probably don’t use many of the tools in the .NET space or at least they hadn’t been using them during the Wasabi Era.

Finally, I don’t see it necessarily as a disaster that people have to rewrite software once in a while. Sometimes, a business can only afford to spend so much money building an application. If the business grows, maybe they will throw out what they have to and get something better. Just as they would buy a larger conference table or bigger coffee maker after throwing what they have into the dumpster. Sometimes, the smaller investment helps them get to the next level, where they have to spend more money.


mgb October 14, 2009 at 10:36 am

I think the problem is that many tools don't grow with the developer. You either know them or you don't.
Convention over configuration is still a relatively new idea that aims to fix this. The tool does something sensible by default and as you learn about it you can modify its behavior in more complex ways.

If hacking together a quick project and putting together a project "properly" are mutually exclusive, let's blame the tools (or lack of the right ones). And fix that situation.

Krishna October 14, 2009 at 1:59 pm

mgb, you have a good point. As tools get better, it will be easier to write better code. Right now, the problem is that even though convention over configuration, you still have to do quite a lot of configuration.

Mike Marshall October 14, 2009 at 9:00 pm

I think there may be a higher bar of 'minimum features' then there were in the FoxPro/VB days for an "application". A small application today is much larger than a small application back then.
Secondly, in order to meet those minimums the development tools today are much more "rich" -- which in some ways makes them easier, but in some ways brings a higher barrier to entry.

Krishna October 15, 2009 at 10:47 am

People's expectations are much higher nowadays. It is possible to design a simpler application, but people demand more from even the simplest app.

Comments on this entry are closed.

Previous post:

Next post: