Ramblings on software evolution & inertia
A recent post at Nerdblog brought up a number of software engineering issues that interest me--the nature of software evolution, when to refactor, the phenomenon of over-abstraction and the importance of reducing dependencies.
If I had a sufficient block of time, I could write a good deal about each of these, but I only have time for a few occasional thoughts, which may be developed further in future posts.
Fred Brooks and Meir Lehman both offer valuable wisdom on the subject of the evolution of software. The bigger a software system gets, the more it suffers from its own weight. It is true.
I have a few metaphors relating to the growth of software systems. One is a boat. The bigger the boat gets, the harder it is to steer it or move it. It's much easier to steer a kayak than a ship. When a software system becomes ship-sized, it's really hard to get it going or change its direction--much more time and effort are required.
This is the reason I'm horrified by the notion of paying engineers strictly in terms of lines of code written. (I think it's in many ways analogous to paying someone to solve a Rubik's cube on a "per twist" basis.) I am hard-pressed to think of a better means of creating ship-sized software than a compensation system such as that. Ceteris paribus, choosing the succinct solution over the verbose one is crucial.
Rather than the compensating for the most lines of code written, it might make sense to compensate engineers for fewest lines of code written. This should bring an immediate guffaw, because who can't write zero lines of code? Let's clarify that by saying the fewest lines of code that gets the job done--nicely formated, with one statement per line. (In reality, there's probably no feasible way to do this, but it's still worth bringing up the point.) Often powerful, universal solutions come in small packages. When you find them, they're as good as gold.
The concept of density seems germane. It's true the best engineers write the most code, but there are plenty of lousy engineers who produce piles of code. The difference between the two is a matter of density. Those who fail to refactor anything and simply repeatedly cut, paste and tweak can generate mounds of code, but the code, especially in the aggregate, could hardly be called dense code-it's the opposite, which I guess might be called "puffy code"
more when time permits
If I had a sufficient block of time, I could write a good deal about each of these, but I only have time for a few occasional thoughts, which may be developed further in future posts.
Fred Brooks and Meir Lehman both offer valuable wisdom on the subject of the evolution of software. The bigger a software system gets, the more it suffers from its own weight. It is true.
I have a few metaphors relating to the growth of software systems. One is a boat. The bigger the boat gets, the harder it is to steer it or move it. It's much easier to steer a kayak than a ship. When a software system becomes ship-sized, it's really hard to get it going or change its direction--much more time and effort are required.
This is the reason I'm horrified by the notion of paying engineers strictly in terms of lines of code written. (I think it's in many ways analogous to paying someone to solve a Rubik's cube on a "per twist" basis.) I am hard-pressed to think of a better means of creating ship-sized software than a compensation system such as that. Ceteris paribus, choosing the succinct solution over the verbose one is crucial.
Rather than the compensating for the most lines of code written, it might make sense to compensate engineers for fewest lines of code written. This should bring an immediate guffaw, because who can't write zero lines of code? Let's clarify that by saying the fewest lines of code that gets the job done--nicely formated, with one statement per line. (In reality, there's probably no feasible way to do this, but it's still worth bringing up the point.) Often powerful, universal solutions come in small packages. When you find them, they're as good as gold.
The concept of density seems germane. It's true the best engineers write the most code, but there are plenty of lousy engineers who produce piles of code. The difference between the two is a matter of density. Those who fail to refactor anything and simply repeatedly cut, paste and tweak can generate mounds of code, but the code, especially in the aggregate, could hardly be called dense code-it's the opposite, which I guess might be called "puffy code"
more when time permits
posted by metamerist at
9:12 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home