a discussion with russ

i had an interesting email discussion with russ. here the highlights.

russ:
More food for thought:

Only Code Has Value?
by Terry Coatta, Vitrium System
From File Systems and Storage, ACM QUeue, Vol. 5, No. 6 - September / October 2007

What this experience brought home for me is that if you have well-written code, you can easily understand what the code is doing.
However, even the best-written code can't reveal why it is doing it.
That's because the question of "why" is not centered on the code itself, but on the context it operates in and the design decisions made during the development of the system. The best way to communicate those ideas is not code, but comments and design documents. To me this clearly demonstrated that it is not just code that has value.
...
I've been through enough experiences like this that I simply don't believe the "only code has value" proposition. Clearly code is the core value product of the software development process. But it's not the only thing of value, and if we want to maintain and extend our code, we need to gear our software development processes accordingly.

I typically find that many ask about doing something but don't have a clue about why their doing it; other than something like "my boss said so".

aaron
Thanks for the link. On a somewhat similar yet-possibly-opposite theme, take a look at CodingHorror's recent posting, Nobody cares you're your code looks like: http://www.codinghorror.com/blog/archives/001022.html

One of my EE friends constantly says software is a tool to solve a problem. I totally agree with half of that statement. The other half is that the software (documentation included) better be awesome too.

russ:
Yes, I agree that "nobody cares what your code looks like"; just that it works. The problem comes when your code doesn't work and you're not the one trying to fix it. The uglier it is the harder it is for someone else to understand it. In this case uglier means not readable to the point of being decipherable and understood by someone else. In my case, that someone else would include me; a lot of times I don't understood what I wrote.

Yes, I agree that "software is a tool that solves a problem".
Unfortunately, software becomes a problem when it no longer solves the original problem it was written to solve and/or it someone wants it to solve additional problems (the changeability nature of software according to Brooks in "No Silver Bullet"). Then it becomes *the* problem when you need to "fix" or change it.

So what we're still stuck with is how to produce software quickly (number of hours) and inexpensively (number of programmers). Test-driven development may be one practice (it's a discipline) that can help in the area of producing the desired or expected outcome or behavior. But still, no one cares what your code looks like; no one meaning users, managers, and people that don't have to maintain it. It's kind of like cars. No one cares that under the hood things looks like crap as long as the car's outside looks nice and the car runs well and had gas in it.


aaron's thoughts:
after thinking about what russ was saying i'm reminded that different people value different things. project managers have their own priorities. developers have a different set of priorities. and users have their own priorities. they are all different. project success is defined differently amongst the different stakeholders. i think the only ones that truly appreciate that fact are developers. developers need to keep the project manager happy by making something that works. developers need to keep the users happy. and developers need to keep themselves happy (with good code). developers have to worry the most. a good project manager would understand that.