Wednesday Mar 12, 2008

Confusing Complexity With Value

The first in my series of software development sins is confusion over complexity vs. value. More times than I can count I've run across a piece of code or a design that is just way more complicated than necessary. Sometimes this is simply a failure to apply the You Aren't Gonna Need It (YAGNI) principle. Sometimes it's simply someone falling into the sunk cost fallacy; after all, somebody put a lot effort into making something big and complicated, so it's natural they don't want to simplify it -- because that would mean throwing some of it away. Sometimes it's "hey, lookit all this code I wrote!" (even though most of it was cut-and-paste). Or sometimes it's just ego-driven: "Wow, look at this big complex system. Only a jock programmer like me could have possibly created it."

Certainly the above occur commonly enough, but I think there's something more fundamental going on. Complexity often results from a programmer's desire to deliver a more complete or more general solution to some problem. A more general solution is always better than a special-case one, right? This is often the case in something like, say, mathematics. The problem here is that software development is not mathematics: it's engineering. Usually a more general solution does provide some benefit. Often (though not always) a more complete or general solution is more complex. With complexity there are increased costs, not only of implementation, but understandability, maintenance, testing, documentation, support, and so forth. The latter include long-term, recurring costs, and they dominate the cost of initial implementation, yet they're what programmers think about the least when they're designing or implementing something. A decision to make something more complex might seem reasonable when only short-term costs are considered, but it can have long-term consequences that are hard to foresee. The question is whether the benefit of this additional generality outweighs the long-term costs of the complexity.

The engineering reality is that generality, and the complexity that often comes along with it, is just one of the forces acting on any solution in the design space. Remember this the next time you're tempted to make something more complex.

Software Development Sins

Given that the Vatican has recently released a statement describing a modern set of sins, it seems appropriate for me to expound (no, not pontificate) on the sins that can occur in a software development project. I was tempted to title this "The Seven Deadly Sins of Software Development" but (a) it's a cliche and (b) it's been done before. Many times. (Search for "software seven deadly sins" and you'll see what I mean.)

More to the point, these sins aren't necessarily deadly. They might even occur on successful software projects. Such software projects might be a lot more painful than they would be in the absence of these sins. So, perhaps these sins can be considered venial. I'm not sure if Wikipedia's theology is to be trusted, but I'll run with it. The criteria listed for a sin to be considered venial ("forgivable") is that (a) it does not concern a grave matter, (b) it is committed without full knowledge (in other words, in ignorance), or (c) that it is committed without deliberate and complete consent. Most sins committed during software projects meet one or more of these criteria.

In addition, I didn't want to constrain myself to seven sins. I'm sure I could come up with seven but I might have to pad the list a bit. On the other hand, I might think of more later, so I've made this an open-ended list. Always the optimist, I say.

Meanwhile, on to the first sin!

About

user12610707

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today