4 ms·

The innovation tokens concept seems to be a stand-in for both good engineering judgement and iterative exploration of the design/implementation space before com

The innovation tokens concept seems to be a stand-in for both good engineering judgement and iterative exploration of the design/implementation space before committing to a path. I've been in several (successful) startups that leveraged both of these principles to great effect. Both "innovative" and "boring" can shoot you in the foot. TFA focsues on "innovative" as a risk, but that's just daft. This industry is constantly rolling its lessons learned back into its shipped and shared technology. Ever gone back to a pre-Rails era web/backend codebase and screamed in horror? Ever gone to a "new" shop that never assimilated those lessons, used "boring" technology (thus dodging their shared/encapsulated forms), and recreated the old horror? (personally: check and check) Trite policies are not a replacement for spending dedicated up-front (and occasional ongoing) time cycling between 1) evaluating/understanding your problem, 2) researching the current state of the art {processes, technology, etc.} related to your problem, and 3) using good engineering judgement to choose the best path then-and-there.

taeric 12y ago
Worse than shops that are still using boring technology, are those that are in some wasteland of inbetween an old technology and a new one.
davedx 12y ago
> iterative exploration of the design/implementation space before committing to a path This is something worth fighting for, but by God, it's a hard fight, both in big corps and smaller "more agile" companies. Great comment, anyway.
deleted 12y ago
[deleted]
smacktoward 12y ago
> Both "innovative" and "boring" can shoot you in the foot. This is true, but it misses one of the points of TFA, which is that with boring tech you already know the ways it can shoot you in the foot, because lots of people have had their feet shot by it before you came along. You can learn what not to do just by looking around and seeing which sets of feet have the smoking holes in them. With exciting tech, you don't know; you get to be one of the people who discovers those things.
- coolsunglasses 12y ago
  I guess I do know the ways in which CGI-based web applications shoot me in the foot because I wrote them in Python and Perl. Said knowledge is why I no longer use: 1. CGI 2. Python 3. Perl
  - proveanegative 12y ago
    Did you stop using Python and Perl for performance reasons?
    - pjmlp 12y ago
      Not the OP, but using TCL in the first .com wave taught me that any language without JIT or AOT support on their toolchains are bad fit for anything that needs to scale. As such I only use Python for scripting.
      - defen 12y ago
        PyPy works with most Python code
        Ixiaus 12y ago
        Please. Don't. PyPy is not mature and still suffers from many deficiencies in python itself and the community. I'm not a huge fan of Ruby, but Ruby, its community, and rubinius are doing it much better.
        jrochkind1 12y ago
        I do most of my work in ruby and am a fan of it (less of some decisions it's community makes, but I'm still okay with it)... and I shy away from rubinius because I don't think it has enough to offer to justify the non-boring risk/tax. I don't want to be discovering that some gem I use (perhaps only a couple versions after i start using it) isn't compatible with rubinius. Even if it's a small risk (and I honestly am not sure how much of a risk it is), for what? Slight performance edge? I don't need it. Multi-core parallelism? I usually don't need it, and if I do, I'm going to choose JRuby (reluctantly).
Retric 12y ago
I have seen some incredibly good 'legacy' codebases written with vary old tech. There is a huge advantage when someone works with a technology for 10+ years and knows all the rough edges to avoid and then bakes it into their design. Java may be the worst example of a ‘bulb’ language I can think of. However, I recently spoke with a team which had an awesome response to all the things I hated about the language. The closest analogy I can think of is mechanics working on popular cars get to the point where they can diagnose problems in seconds because they know the kinds of things that break. Cars come with plenty of sensors to help diagnose problems, but in this case familiarity often beats better tools.
- cheepin 12y ago
  Being an expert at something is not equivalent to saying that thing is boring. One insidious danger of "boring" tools is how they lull developers into complacency. "You can’t pay people enough to carefully debug boring boilerplate code. I’ve tried." -Yaron Minsky
- Johnny_Brahms 12y ago
  We are still a freepascal shop and it works flawlessly. Every now and then someone wants to do a rewrite in something fancy, but we really have nothing to gain. The current codebase is actually quite pretty, compiles fast, and is easy to maintain. New hires don't need more than a week or two to get the gist of everything. The web frontend has been migrated from perl though. It got the job done, but it wasn't pretty and nobody dared touch it.

taeric 12y ago

Worse than shops that are still using boring technology, are those that are in some wasteland of inbetween an old technology and a new one.

davedx 12y ago

> iterative exploration of the design/implementation space before committing to a path This is something worth fighting for, but by God, it's a hard fight, both in big corps and smaller "more agile" companies. Great comment, anyway.

deleted 12y ago

[deleted]

smacktoward 12y ago

> Both "innovative" and "boring" can shoot you in the foot. This is true, but it misses one of the points of TFA, which is that with boring tech you already know the ways it can shoot you in the foot, because lots of people have had their feet shot by it before you came along. You can learn what not to do just by looking around and seeing which sets of feet have the smoking holes in them. With exciting tech, you don't know; you get to be one of the people who discovers those things.

coolsunglasses 12y ago
I guess I do know the ways in which CGI-based web applications shoot me in the foot because I wrote them in Python and Perl. Said knowledge is why I no longer use: 1. CGI 2. Python 3. Perl
- proveanegative 12y ago
  Did you stop using Python and Perl for performance reasons?
  - pjmlp 12y ago
    Not the OP, but using TCL in the first .com wave taught me that any language without JIT or AOT support on their toolchains are bad fit for anything that needs to scale. As such I only use Python for scripting.
    - defen 12y ago
      PyPy works with most Python code
      - Ixiaus 12y ago
        Please. Don't. PyPy is not mature and still suffers from many deficiencies in python itself and the community. I'm not a huge fan of Ruby, but Ruby, its community, and rubinius are doing it much better.
        jrochkind1 12y ago
        I do most of my work in ruby and am a fan of it (less of some decisions it's community makes, but I'm still okay with it)... and I shy away from rubinius because I don't think it has enough to offer to justify the non-boring risk/tax. I don't want to be discovering that some gem I use (perhaps only a couple versions after i start using it) isn't compatible with rubinius. Even if it's a small risk (and I honestly am not sure how much of a risk it is), for what? Slight performance edge? I don't need it. Multi-core parallelism? I usually don't need it, and if I do, I'm going to choose JRuby (reluctantly).

Retric 12y ago

I have seen some incredibly good 'legacy' codebases written with vary old tech. There is a huge advantage when someone works with a technology for 10+ years and knows all the rough edges to avoid and then bakes it into their design. Java may be the worst example of a ‘bulb’ language I can think of. However, I recently spoke with a team which had an awesome response to all the things I hated about the language. The closest analogy I can think of is mechanics working on popular cars get to the point where they can diagnose problems in seconds because they know the kinds of things that break. Cars come with plenty of sensors to help diagnose problems, but in this case familiarity often beats better tools.

cheepin 12y ago
Being an expert at something is not equivalent to saying that thing is boring. One insidious danger of "boring" tools is how they lull developers into complacency. "You can’t pay people enough to carefully debug boring boilerplate code. I’ve tried." -Yaron Minsky
Johnny_Brahms 12y ago
We are still a freepascal shop and it works flawlessly. Every now and then someone wants to do a rewrite in something fancy, but we really have nothing to gain. The current codebase is actually quite pretty, compiles fast, and is easy to maintain. New hires don't need more than a week or two to get the gist of everything. The web frontend has been migrated from perl though. It got the job done, but it wasn't pretty and nobody dared touch it.