Implementation Does Too Matter

Many have argued that the internals of software - how it is implemented - is irrelevant, as long as the end result - the functionality, features, and correctness - are the same.

I would beg to differ.

(Really, this was inspired by RoyFielding 's classic dissertation, in which he analyzed the architecture of the Web and HTTP. It succeeded not because it did more, but because of how it was implemented.)

How does implementation matter? Three ways:

Flexibility
Robustness
Adoption

Flexibility - How easily can the system be changed? How well will it handle other things changing, and unexpected conditions? How easily can parts of it be mixed and matched, and alien parts put in?

Robustness - How will it handle errors? How visible and transparent is it? How secure?

Adoption - How easy is it for other people to learn it? Deploy it? Interop with it?

Consider two companies exchanging sales data, either via XDR over RPC, or simple XML over HTTP. Both can do the exact same features. But the winner is the one with the better implementation. Likewise, for a small cron job, a large bash script, or a Ruby file. Again, both have the same functionality. It's the implementation which makes the difference.

I think this page is based on a strawman argument. Experienced software developers don't argue that implementation is irrelevant, in general. They argue that it is irrelevant to certain (important) aspects or stages of software design. The ability to work with varying levels of abstraction when designing a system is a critical design skill, which requires being able to focus one's attention on a certain way of looking at a system or subsystem while omitting details that are not relevant to that particular view. Good designers move easily between different levels of abstraction, and have a good sense for the pros and cons of these simplifications at each level, bringing the details back into the picture when it's important to do so. Implementation characteristics may constrain what abstractions are realizable and effective; but the abstractions should also be able to stand on their own, making them easy to understand in relative isolation from the rest of a system.

Coplien's "Multi-Paradigm Design for C++" (ISBN 0-201-82467-1 ) discusses explicitly the tensions and relationships between abstraction and implementation considerations.

It should be obvious to any practitioner that quality of implementation has a profound effect on the maintenance and evolution of a system.

-- DanMuller

"Experienced software developers" don't argue that implementation is irrelevant, but there are some prominent Wikizens who argue precisely that. And as far as the general public is concerned, it's generally true - the quality of the implementation comes into play only when requirements change, and then it's because different implementation strategies lead to different timescales for new features. So it's not a complete strawman. -- JonathanTang

Yes, the initial inspiration for this page was when I tried to explain to a client that work delivered to him, while functional, had poor craftsmanship. His response - which I understand - was "Who cares?" As craftsmen, we are pained to see shoddy work. But I had to press myself to see if, in the end of the day, craftsmanship would affect him.

"And as far as the general public is concerned, it's generally true" ... which supports my point. It depends on the point of view. I still find it hard to believe that any developer would argue that implementation never matters. It all depends on context. -- DanMuller

Saying "implementation doesn't matter" is the same as saying "only external quality matters. Internal quality doesn't matter". See InternalAndExternalQuality.

Sometimes teachers accidentally stick this false idea into the heads of beginning programming students, when they try to explain how comments and indentation are ignored by the compiler. (Is this bad teaching, or just another example of WittgensteinsLadder ?)

After a program is compiled, burned into a ROM, attached to a space probe, and launched into space, the implementation of that particular piece of software no longer matters to the success of the mission.

I would argue that it does, as it impacts *Robustness*

Robustness is a component of external quality. The above comment is talking about components of "craftsmanship" that affect only internal quality. Incidentally, I think you mean 'affect' rather than 'impact'--if the space probe is impacting anything, then I hope that's its purpose--otherwise, there really is a robustness issue.

Actually, even space probes millions of miles distant aren't fully released. Many probes allowed reprogramming mid-mission, which was handy to reroute functionality around broken hardware, and to adapt the mission profile based on data gathered. In this case, internal quality was extremely important.

Programmers quickly learn that the implementation does too matter in the time between someone starts to type in the rough draft of the program, until the program is compiled for the last time.