5 ms·

Three Kinds of Code

8 points by mcormier 17y ago

Tichy 17y ago
"Code that’s built to last. Well factored, well understood by the team, with strong automated tests, and generally meeting the team’s standards for something they’d happily maintain forever." Name an example of code of that kind?
- olliesaunders 17y ago
  Pretty much all code can potentially be run for a long time and be subjected many alteration requirements, making high quality dev practise worthwhile. But if you want a archetypal example: libraries.
  - warfangle 17y ago
    Some libraries. And then there are libraries like Prototype and Scriptaculous.
    - Tichy 17y ago
      Are they good or bad examples?
  - Tichy 17y ago
    I'd expect few libraries to still be very pleasant to work with after a couple of years. For starters, one might not even want to use the programming language they were written in anymore.
DenisM 17y ago
Another way to bridge the communication gap is to introduce the notion of "engineering debt" aka "technical debt". If you can quantify the day-to-day impact ("the interest payments"), amount of work it would take to fix it ("the principal") and the ongoing accumulation of crap ("the negative ammortization loan") you will be loved by both engineers and managers.
- Tichy 17y ago
  Still, there is the 90% rule that code can not overcome, either: 90% of everything is crap (except crap, 100% of crap is crap).
  - DenisM 17y ago
    That's just engineering nihilism speaking. :-) Surely the code you wrote last week was not 90% crap?
    - Tichy 17y ago
      To be honest I assume that most of my code is crap. Otherwise I would never get started because I would be stuck with architecting for the next 2000 years.
sunkencity 17y ago
I think the key to write fast code is to compartmentalize. Write someting crappy but that's walled off into a class, or file so that it can be thrown away later on. I'm a bit tired of the notion that all code needs to be ready for a mission to the moon, or needs to be reusable. It doesn't -- it just needs to do the job. If part of the job is to be the foundation of years of work to come, then yes, it needs to be brilliant. If the code you are writing is a quick hack to generate some images or to present some data on a single web page, time matters more than that is can be extended ad infinitum. Write something quick -- and maybe you can have the time to write some tests as well.

8 points by mcormier 17y ago

Tichy 17y ago

"Code that’s built to last. Well factored, well understood by the team, with strong automated tests, and generally meeting the team’s standards for something they’d happily maintain forever." Name an example of code of that kind?

olliesaunders 17y ago
Pretty much all code can potentially be run for a long time and be subjected many alteration requirements, making high quality dev practise worthwhile. But if you want a archetypal example: libraries.
- warfangle 17y ago
  Some libraries. And then there are libraries like Prototype and Scriptaculous.
  - Tichy 17y ago
    Are they good or bad examples?
- Tichy 17y ago
  I'd expect few libraries to still be very pleasant to work with after a couple of years. For starters, one might not even want to use the programming language they were written in anymore.

DenisM 17y ago

Another way to bridge the communication gap is to introduce the notion of "engineering debt" aka "technical debt". If you can quantify the day-to-day impact ("the interest payments"), amount of work it would take to fix it ("the principal") and the ongoing accumulation of crap ("the negative ammortization loan") you will be loved by both engineers and managers.

Tichy 17y ago
Still, there is the 90% rule that code can not overcome, either: 90% of everything is crap (except crap, 100% of crap is crap).
- DenisM 17y ago
  That's just engineering nihilism speaking. :-) Surely the code you wrote last week was not 90% crap?
  - Tichy 17y ago
    To be honest I assume that most of my code is crap. Otherwise I would never get started because I would be stuck with architecting for the next 2000 years.

sunkencity 17y ago

I think the key to write fast code is to compartmentalize. Write someting crappy but that's walled off into a class, or file so that it can be thrown away later on. I'm a bit tired of the notion that all code needs to be ready for a mission to the moon, or needs to be reusable. It doesn't -- it just needs to do the job. If part of the job is to be the foundation of years of work to come, then yes, it needs to be brilliant. If the code you are writing is a quick hack to generate some images or to present some data on a single web page, time matters more than that is can be extended ad infinitum. Write something quick -- and maybe you can have the time to write some tests as well.