Slashdot Mirror
Why You Should Choose Boring Technology
An anonymous reader writes Dan McKinley, a long-time Etsy engineer who now works at online payment processor Stripe, argues that the boring technology option is usually your best choice for a new project. He says, "Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble. ... The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."
A personal corollary for code related to this theme is to always try to make the code I write as "boring" as possible. I've found that programmers often get themselves in trouble by trying to be "clever", which often makes for horribly unintuitive or unnecessarily complex systems. I've heard people asking about how to perform crazy language tricks and I nearly always think to myself "My God, why in the hell would you even *think* about doing something like that?" Such things nearly always point to very fundamental flaws elsewhere.
Irony: Agile development has too much intertia to be abandoned now.
It's the same reason that your own small company should be trying to implement its own CRM (assuming that's not its core business), or drastically changing the way that it considers sales compensation. Being revolutionary in one area is hard enough - don't make anything even harder than it has to be.
You're special forces then? That's great! I just love your olympics!
Mature technologies are proven. They've gone through their growing-pains. They may have limitations, but those limitations and workarounds are usually well known by seasoned professionals. There's a reason why COBOL, Fortran, and RPG are still in use in business applications almost sixty years after their initial development, because they reliably work.
I've tried to work with NodeJS projects for production. It's a nightmare. NodeJS itself is revised too often, the actual project is revised too often, and the dependencies became a nightmare. It's not mature enough and not worth it.
Do not look into laser with remaining eye.
In about 1996, Oracle introduced the "Oracle Webserver", allowing you to serve dynamic webpages generated from stored procedures in the database. The beauty of this is that all of your website code is in the database, making it centrally managed and all application security logic is enforced by the database. The webserver is just a dumb client with no code, and has no permissions on any database tables.
In 2001, it was now a mod for Apache and as since been opensourced (mod_owa). I convinced our client try it for a central website that we were developing, as the middle tier crap they were using didn't work. That system went live 2 weeks later with a few very simple webpages. It has been in production ever since and the website has over 50k users and 20+m hits a day.
"Be grateful for what you have. You may never know when you may lose it."
Hey, everyone here still reads Slashdot!
I've recently been getting more heavily into javascript (proper apps, not just UI animation snippets). The whole scene is a mess. You try to learn about good code structure and you've got crockford saying use constructs to simulate classical OO and then a whole lot of other coders giving you really good reasons to use prototypical inheritance and stop trying to simulate a classical language. Then a whole other bunch are telling you to use coffee script but others point out the difficulties debugging it so then you should use typescript because it will eventually be ecmascript6. Once you get your head around the code structuring options, you then have to decide whether to just use jquery or an mvc like ember or angular. And when you choose a shiny new bbc because it is easy you realise that two way data binding makes your code super slow and start having to hack away at it to get it working on a mobile targets. Oh and don't forget the TDD framework unless you go for BDD because that is the new thing. And then do you use the closure compiler, requirejs for amd or should you even use amd at all.
I will happily go with tried and tested, if only web developers would stop reinventing things every six months.
I think it is important enough to have atleast one 'skunk-works' type project that every developer needs to work on, just to keep up with what will be boring a year or two down the road.
I avoided "not boring" for a couple of years and for the last month, while I look at hybrid mobile apps, I am stunned by my lack of knowledge and the abundance of terms, concepts and technologies that mean nothing to me ... angular, ionic, grunt, promises, JSX, reactjs, compass, gulp, firebase... the list could go on and on and on, these are just things I've started researching over the last few weeks, to make sure I make the right choice.
Every organisation needs a "not boring" slot of time for their developers. Not for product that needs to ship NOW.. but for stuff that may need to ship next year.
It's like Rincewind said: "I like boring. It lasts."
-- Cheers!
This basically sums up things I've said over the years and thought about. You and your team have a problem to solve. Anything that gets in the way of solving that problem is the wrong solution. Learning a bunch of new tech looking for a silver bullet or because it is 'kewl' is the wrong answer. There is the learning curve to consider as well as the instability inherent in a new tool set which needs to be understood when making these decisions.
What is even more distressing is when you see bad ideas return like bad pennies, network databases are now graph databases for example. ACID compliance sacrificed for 'speed'. Having to write you own threading management code. Those immediately pop into my mind. Sure, there may be some short term gains but what about 5 years from now? After a huge investment throwing something away and replacing it becomes difficult and expensive. I am looking for the citation but I once heard that the maintenance costs of software far outstrip development costs by about 10 to one.
My advice is to first learn the problem domain which includes keeping a long term view in mind, then pick the tool set with a bias towards the tired and true workhorses. Spend less time thinking about your tools and more time solving the actual problem.
putting the 'B' in LGBTQ+
As someone who has a lot of Perl on his resume, I heartily endorse companies hiring people who work with boring old technologies!
There's a reason I choose Debian Stable for my servers.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
For a second I thought this was a Bennett special.
The summary is much too short for that. If it took you a full second to recognize that, I wouldn't put any more quarters into the whack-a-mole machine if I were you.
If your developers are really excited about the stuff they are doing then chances are the ops people looking after the 'finished product' (note the quotes, please) are going to have 'exciting' jobs (again, quotes).
In the free world the media isn't government run; the government is media run.
Infrastructure is "boring", but somebody's gotta build and maintain those old roads. Go Civil Engineering!
Townsend wrote about a powerful idea, of the perfect note. Clapton, who crossed paths with Townsend, preferred a simple guitar lick to communicate his ideas. I started as a business consultant with software skills, and I've always considered -- even now as a consulting developer -- a line of code to be the last resort when all else fails -- because of the cost involved. Back before the concepts had buzzwords, I advocated 'just in time' development over 'just in case', and that if you're writing a lot of code you're probably doing it wrong. These days it's called Emergent Architecture on a formal level, and YAGNI informally. Every line of code, every expansion of the technology footprint, should be when all else fails.
Oddly enough, I've seen that cause more problems than it's solved.
It's often misinterpreted, in the same way you so conveniently put it, which is then used to justify some pretty awful decisions regarding third-party libraries. I'm convinced that this is the leading cause of bloated software.
Even when used correctly, I've seen some pretty impressive code-contortions to avoid even a very small amount of duplicate code. Sometimes, it's okay to just do a check twice. As long as the code is easy to read and modify, you're fine. Really.
But that's the problem with programming, isn't it? It's little more than wishful thinking and folk-wisdom. That would be okay (it's an art, after all) but too many developers have deluded themselves in to thinking it's more in-line with mathematics or engineering. They've convinced themselves the cute little acronyms they repeat to one another have some objective, rational, basis and must be obeyed at all cost.
It's silly, really.
Required reading for internet skeptics
Personally I think that one of the problems with software development is that we don't treat it like engineering enough. Not engineering in the sense of building a bridge, but engineering in the sense of design (designing a circuit for example). Engineering is inherently a pragmatic discipline where creativity is constrained by various physical, budgetary, and time constraints. Because software has less of the physical constraints, I think that the "art" side can get a little carried away at times. But the main issue is lack of discipline; and that is more of an artefact of the culture that can be associated with software development, rather than anything inherent in the work itself. I'm biased (with an engineering background), but I think that many software companies could benefit from the attitude that comes with engineering.
The same thing happens with the hope for the "next generation" product solving all the ills of the current generation. Or the assumption that the code you have inherited was created by fools a number of years back.
The reality is that software has a set of maturity related bugs and a set of structural, intractable issues that are related to the design and architecture of the system. Each piece of software has it's unique set of intractable issues.
Software that has been in production has typically reduced it's maturity related bugs. The software built on top or that integrates with it is built around those intractable issues. When you move to a new piece of software - either a new architecture or the "groundbreaking ng version of XYZ", you end up with swapping a set of *known* intractable issues, for a set of *unknown* intractable issues plus a set of maturity related bugs.
Similar to TFA, the risks of old+known vs new+immaturity+unknown needs to have another factor similar to "value-add". If the value-add *really* adds a lot of stare the risks in the eye and march forward. If the value add is marginal, make sure the meta-benefits (performance, maintainability, etc) are clear and understood, otherwise you may be facing a train wreck of an upgrade.
Seen it many times, always wary of the ngXYZ project...
> with the sole exception that all other things being equal clearly the more exciting one will pay bigger dividends due to increased developer interest.
I'm afraid that's the fine print. "All other things being equal". All other things are not equal. "Boring" technologies tend to have a competent, with documentation, load testing, and syntax checking tools. New technologies to "get the project done" often not only fail, but even when they work fail to scale, and introduce _another_ complex environment to manage.
When it comes to offerings from Oracle or Microsoft, you in fact want to go with an older, more proven solution that is still supported for long time. But with open source, this will get you burned because all the developers got bored and went to work on something else. With newer projects, there will be bugs but also people fixing them, often quickly and for free. As far as comparison between the two, it comes to scale. If you are lucky enough to create a popular consumer product, at some point costs of proprietary vendor support will become prohibitive compared to in-house development. Also, you may find yourself in direct competition with your supplier and not want to give them all this money even if they are willing to support you. For internal business apps, the equation is often the opposite and you would rather pay for someone than do software development which is not your core competency.
I'd once written what I thought at the time was a fairly simple C program to interface with a medical lab system, calculate the checksum (a very, very basic CRC), and pass the results to a file. For the record, I'm a self-taught programmer who started with the Data General Nova assembler, but I digress....Several years later, I happened to meet a programmer who'd inherited my code and, basically, said that it was the best commented, self-explanatory code he'd ever seen and later changes were really easy to make. At the time, I'd just written a device driver was so feeling all punky, but later I realized that what that dude had told me was the highest compliment I could ever receive. $.02 brothers and sisters....
Yes. There is no sense in saying "All other things being equal"; that is the point that leads to the fact that it doesn't make any more sense to say "Boring" technologies tend to have a ...". 'Boring' isn't a technology classification. Period. Stop being an idiot and acting like it is.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Case in point: Look at the religious hatred for "goto" that has no real technical basis anymore in modern languages.
A bullet may have your name on it but splash damage is addressed "To whom it may concern."
Yes, but his brilliance was in minimising the number of components required to perform a certain function. His "art" was in solving two pragmatic problems. a) Correct function of device and b) minimising the costs (components). The constraints (physical and budgetary) are what channeled his creativity.
"Let's say every company gets about three innovation tokens."
Bullshit hypothetical statements are bullshit.
BeauHD. Worst editor since kdawson.
I'd never trade readability for "elegance" or, worse, "performance".
Code golf may be fun, but it needs to be kept very far away from everything outside those games.
Required reading for internet skeptics
And there are usually more training material, tutorials, and road-tested reference info for older stuff. Look one version back and you can get $7 books even. Established technologies don't change that much between versions such that say a book for version 7 won't be much different from the latest, version 8. You can usually find a "what's new in version 8" article on the web for the differences so that you don't have buy the latest book.
Table-ized A.I.
but where is the justification for all those impressive job titles in your approach ?
What he suggests has a lot of merit. On the other hand, there are so many companies languishing under inappropriate technology whose problems would be solved if they weren't so boring. Applications that would be transformed if they only used an object database for example. Business logic that would actually be maintainable if they used a functional programming language. Unmaintainable COBOL that would benefit from an object approach. Yes, there are a lot of times you'll ship something faster by being boring. But whether you'll get the best quality? Not so sure.
You have a good point, but only most of the time.
Thomas Kuhn, in the context of science, spoke of 'normal' and 'extraordinary' science. Normal science was as you described; you stay in the paradigm and follow the conventional methods for resolving issues. However, these methods did not appear out of nowwhere; somebody was being a clever cowboy and decided its time to do things different. This is where revolutionary science came in. Of course most of these innovations - like any innovation - fails miserably. But if it wasn't for all the failures we would never have the successes that change paradigms and got us to the methods we use today.
And I think this dichotomy does apply to almost every human endeavor.
That said, for normal day to day operations, being a cowboy ALL the time is foolhardy and dangerous. But for people to NEVER have a little bit of an experimental and innovative mindset is also risky in its own way. Sometimes this is balance (known as a bimodal or barbell strategy) is maintained within a single individual by balance of exploiting the traditional and exploring the novel; sometimes its divided between individuals, with a good balance keeping more people stable than unstable.
However the wheel can still be improved. I sure wouldn't want solid wooden wheels on my bike.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Sometimes, it's okay to just do a check twice
No, it's not. Because now if you need to change the check (or more likely someone else) you have to make sure you do it in both places. If the other person does not even look for the second check then you now have broken code. If you have to copy paste your own code with minimal or no changes then you are doing it wrong and it's time to refactor.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
>developers have deluded themselves in to thinking it's more in-line with mathematics or engineering
Except of course that it IS mathematics. Indeed if engineering is the application of scientific knowledge to the solving of practical problems -then programming is the engineering of the science of mathematics.
From the point of view of a computer every program is just one big number. You can reproduce any and all programs that have or ever could be written by simply counting in binary for long enough.
Yes, count long enough and check the results at every count and eventually you will have a number that, if executed, is microsoft outlook.
That is, however, a rather inefficient way to find useful numbers - to get to outlook THAT way would take centuries even on the fastest computers we have.
So what is programming ? It's a sophisticated way to take shortcuts, to find useful numbers without counting through ever possible number (most of which are not useful at all - i.e. if you dump it as a binary to a file it wouldn't run).
That sophistication of figuring out what the program should do first (i.e. defining what the number should be useful for) and then counting in large chunks (i.e. writing components that help satisfy that over-all design goal) is a form of engineering.
It's a highly creative form of engineering and it is very much an artform too. Art and engineering are generally much more closely related than we usually think: just consider the Eiffel Tower, or ask any sculpture about the constraints the laws of physics place on his designs and choice of materials.
Programming, at least at it's current stage of knowledge, is still at a point where the line is extremely blurred and techniques from both art and engineering can be very valuable.
Over time we may find that it becomes more the one or the other, depending on what produces the best results the most efficiently - but I wouldn't trust any wager on which way it would ultimately go. I will say it would never be just one or the other, by it's very nature it will always have at least some elements of both.
Unicode killed the ASCII-art *
I had a colleague circa 1999 who wrote a neural net in Javascript. And keep in mind when I say javascript I don't mean the JS of today, I mean JS as it was in 1999 - generally considered useless for anything more than onmouseover image rolls.
Why ? To see if he could. It did work though I think his net had only 16 nodes.
Unicode killed the ASCII-art *
Don't repeaty yourself (DRY).
Didn't you just say that?
-- Make America hate again!
Is Bennet still allowed to post? I haven't seen any of his ramblings for a while.
I tried very hard to convince my manager that we should do this on a project that used DB2. She was adamant that we would have to write the web services with the full Java stack. Hundreds of thousands of lines of java later (complete with maven, spring, hibernate, ad nauseum) she is no long with the company and the project is cancelled.
The original justifications for hating goto referred to a non-local goto (or, exceptions, as the kids call them these days) which made it very difficult to reason about control flow in a program. The new reasons for hating goto in language like C/C++ relate to variable lifetimes and making it difficult to reason about when variables go out of scope.
I am TheRaven on Soylent News
Except of course that it IS mathematics.
And the obligatory: xkcd
Every time some links to the obligatory xkcd, I remember the numbered jokes joke.
Except that usually I don't need to follow the link nor see the number to know what joke it is referring to.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
You use a very dry description, "minimizing the costs", for things Woz did that I am sure you would lambaste as "carried away" if he'd been working purely in software:
1) replacing dozens of chips for synchronizing data I/O with disk rotation with a software implementation
2) omitting Shugart's Track-0 sensor by having the controller simply move 40 times toward the next-lower-numbered track and relying on the mechanical stop to prevent it going any further down than track 0
3) taking advantage of the way that 6502 instructions only access memory every other clock cycle, the video generation circuitry's memory access on the otherwise unused cycles avoided memory contention issues and also eliminated the need for a separate refresh circuit for the DRAM chips
4) choosing to use a simple timer circuit whose period was proportional to the resistance of the game controller instead of a complex A/D circuit
5) I'm not even going to try to summarize his hacks for handling NTSC color with less hw
I believe 'goto' has been replaced by the 'if' statement. I believe that 'if' statements should be used very carefully.
I am not so sure about this statement. The 'goto' can be used for both conditional and unconditional branches. The 'if' statement, 'do-while' loop, and/or 'for' loop are conditional branch. If your variables are not dynamic, you may not need a branch.
Also in modern languages, you should not try to optimize or be too clever in how to style your code if the language has compiler because you don't know what and how compiler is going to modify your code. Yes, the source code may look discontinue, as long as it is clear and maintainable, it is a fair enough code.
Being on the bleeding edge is expensive. Who knew?
Most of the time going for the already-proven technology that solves the problem will provide the best value.
"...to get to outlook THAT way would take centuries even on the fastest computers we have".
Which would still be FAR FAR TOO SOON.
I am sure that there are many other solipsists out there.
It's often misinterpreted, in the same way you so conveniently put it, which is then used to justify some pretty awful decisions regarding third-party libraries. I'm convinced that this is the leading cause of bloated software.
.
No, thought not. IMHO a classic - almost, in fact, the canonical - example of boring technology that's good because it's boring. Look at all the criticisms of Ada, and you will find that most of them boil down to, "It's not so much fun and doesn't make me feel so good". But that depends on what makes you feel good. As many qualified people have remarked, if you are flying in an airliner you really want the avionics to be written in Ada, not C++ or Ruby or Python. Why? Because you're a lot more likely to survive. Almost unbelievably, it boils down to a matter of professional pride. What gives you a warm feeling - coding something marvellously clever that you yourself won't understand in three weeks, or creating something that works reliably and does exactly the job it was meant to do? One is an amateur attitude, the other is a professional attitude.
I am sure that there are many other solipsists out there.
Now if only he can come up with an easily remembered acronym to remind people that they should keep these things simple as much as possible, or else they are stupid.
I also don't want a broken, poorly documented, no-longer maintained or serviceable wheel.
People are finally realizing the problems with things like "game engines."
Yeah yeah yeah, a game engine does tons of things for you. But it also forces you to do things a certain way, and can make tracking down bugs on THEIR SIDE extremely difficult. The time you save by "having it run out of the box" should be considered against the time it takes to "learn the API" and "learn the engine's quirks" and the huge cost of not being able to modify certain parts of the technology as needed. There's also the trade off of "is my new code making new bugs?" vs "Is their framework hiding bugs from me?"
It's not a simple, easy decision to make.
While more obvious with game engines, the same applies to any foreign piece of code. There is no such thing as magically re-usable code. All code needs time and energy to understand and work with, and no framework is magically going to let you treat a complex problem like a simple problem. It may hide the complex decisions, but if those decisions are wrong, you've got yet another headache.
Boring technologies have usually been around awhile and there is usually a reason for that. Typically they are pretty good for what they are being used for. As a result there are usually a lot of support out there as well as large code bases. Lots of documentation. Resources not only in libraries, code, docs, but also in staff that understand the technology, so it is easier to bring someone in, have them understand what is there, and make what changes may be necessary quickly without a lot of downtime. So yeah, while they are not the most sexy of technologies, they are the core of what gets things done. I'm not just saying that because all my coding is in antiquated languages at this point (I don't do all that much coding really anyway).... :) That said, I recently took a course to "upgrade" some of my experience, and it was developing using PL/SQL which isn't exactly mind bendingly new technology... But you know what? If you use an Oracle DB as a back end (which a big chunk of the world does), having PL/SQL is certainly a useful technology to have under your belt...
This problem isn't just in pure developer-land.
As an example, meander on down to the PuppetForge and look at the common modules used to do boring stuff.
For example, installing and maintaining PHP on a box via Puppet should be drop-simple, with little-to-no work... I designed and wrote a simple module for it in like 30 minutes, spending 15 minutes of that having a cigarette, no sweat. But one look at some of these, and you'd think they were writing Turing-capable climate modeling software. Okay, I exaggerate (a little), but the point is, these guys spend untold hours trying to turn a set of car tires into jet engines.
Here's where it gets ugly: Most DevOps folks liberally download these beasts and implement them, never realizing (until it's way too late) that the vast majority of these modules are written either to be cute, to be clever-by-too-far, or to bolster someone's resume ('look, I'm a coding deity!' type crap***). They then spend hours on end busting their ass trying to get these damned things to work in their environment, and end up with something that quite frankly eats more CPU cycles and disk space then it really should... by orders of magnitude.
TL;DR? The greatest wasting of time I've seen in development and beyond is when people try to get too cute or too clever with code.
*** if someone showed me some of these ugly-assed bloat-factories as part of the interview process, they would face some damned hard questions from me about design before I'd even think of recommending them to be hired.
Quo usque tandem abutere, Nimbus, patientia nostra?
That's why the article didn't suggest not using them. It suggested only using a few of them at a time, backfilling with boring, well-understood technologies, so that you're not betting the farm on a house of cards when nobody's making you do that.
The odds that your business problem requires or can even benefit from a brand new language (that you can't hire for), a new storage system (that you can't find dev-ops support for in your data center), the latest methodologies (that nobody knows, hello training cost), et cetera, all at once, is just ridiculous.
You're special forces then? That's great! I just love your olympics!
Every 'if' statements creates a discontinuity in a function, ask a mathematician why discontinues functions are ugly.
Not every "if" statemet does this; it depends on what is inside the if statement. Often they are semantically equivalent to plain old bitops math.
Also, CPUs are rather good at handling conditionals, in fact are designed these days to handle them extremely well, and conditionals are very often what we need computers to actually do to get work done. If FP was a viable approach to real world problems, then successful FP platforms would not be so riddled with cheats and workarounds.
Mathematicians should be consulted to solve complex data dependency problems in isolated subroutines. Listening to what they have to say about the macro matters when it comes to programming leads to doing some really stupid stuff and obsessive golden hammer swinging. This is because problems in the real world (and especially in real time) are arbitrarily complex (and corresponding solutions are approximate) and not amenable to the clean set of prerequisites necessary to "solve" them using mathematical techniques.
Someone had to do it.
Jesse: You're a goddamn artist.
Walter: Why thank you Jesse but it's just basic chemistry.
One of my favorite quotes from Breaking Bad. It really shows the difference in mentality between someone who thinks they know what they are doing and someone who actually does. No respectable computer programmer calls their work art. Its just science.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
By constantly taking the 'safe' option, you can actually end up in a very high-risk stagnant position, where you'll be slower to market, or new entrants can dramatically undercut your cost structure. It's also very easy to end up with millions of lines of inflexible, proprietary code; because you're ignoring new frameworks that your competitors leverage with just 10's of thousands of lines instead.
What I'm not seeing in the market is enabling capabilities.
People always like to talk about language/feature x or framework y or pattern z... yet all browsers, codecs, operating systems, networking stacks, game engines, database engines of import are written in some form of C. Automated porting tools exist and decade(s) have passed...still crickets.
The useful progress I see occurring is locked up in incremental improvements rather than "new ideas" and fly by night projects.
What I really want to see is something transformative ... something where if you don't use it you will be left behind or simply otherwise not have the capability to implement a system like your competitor.
If you take away the game engine or the database engine or the browser or network stack a lot of people would be screwed simply not otherwise have the time, intelligence or capability to implement solutions.
These things were all started decades ago and continuously refined and improved upon with herculean amounts of now dead labor.
Ignoring new entrants who are in too many cases just reinventing the wheel ...poorly... is not a way to be left behind it is a way to get ahead and be successful. The era of "surprise... I found something new... everyone do this now.." is over has been for a while. Betting against it even out of ignorant dismissal gets safer every day.
Products can often live long lives, with most of the cost ending up being in maintenance & future features. But don't just consider the technology you need today, but also consider what will be most appropriate for the organisation in the years ahead too.
The best way to be successful is to heavily invest in architecture and design while de-emphasizing import of syntactic details. If you are having endless meetings over what language or API to use you are already screwed.
Modern languages have much less need for "goto" than the languages back when Dijkstra wrote that letter, meaning that any use is more likely to be part of something that simply shouldn't be done. Modern languages also concern themselves more with blocks and variable lifetimes and initializations, which unstructured "goto"s work badly with. Also, modern compilers rely much more than before on being able to suss out the control flow, which non-structured use of "goto" messes up. I'd say that there's more reason not to use it than there was back then.
Do you have examples or a real technical basis for favoring "goto" nowadays?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
No, it's not science. (It doesn't even remotely resemble science!) Neither is it an application of science, for obvious reasons. I'll maintain that it isn't mathematics or an application of mathematics as well, as while some math is used, it's not where the developers effort is focused. (If you don't like that, ask yourself why there isn't an algebra for computer programs.)
It's more in line with arts and crafts. You'll find far more similarities to painting or sculpting in programming than you will mathematics or science. Interestingly, you'll use quite a bit of math is both painting and sculpting. (You may even find some applied science in those.)
It's just delusional thinking to make some developers feel better about themselves. Consider how many developers don't understand basic logic, despite believing that logic is a fundamental aspect of the work that they do! You might be one yourself. Grab an undergraduate textbook on logic and give it a go. You may find yourself surprised.
Required reading for internet skeptics
if you have 3 lines of identical code in 3 places, it should be a method or function...
less than that you have an identical comment so your IDE can find you all the code when you start to change one of the instances...
Don't be foolish. Dogmatic adherence silly acronyms at the expense of readability is a bad thing. You often end up with more code, not less, trying to avoid any and all redundancy. If it's cleaner and easier to read and maintain, it's worth the exchange.
Let's look at your justification for your dogmatism:
If the other person does not even look for the second check then you now have broken code.
What you've written here, is that if a developer makes a mistake modifying code they don't understand, you'll have broken code. It doesn't look that strong now, does it?
Further, I'd argue that adding more, likely more complicated, code to avoid a tiny bit of redundancy is far more likely to bring about those circumstances where a developer is going to modify code they don't fully understand.
Have you ever played code golf? The idea is to make the shortest possible program that meets some requirement. The most common strategy is to start with a normal implementation and then find ways to reduce the codes size. Essentially, it's about eliminating redundancy. The results look really impressive, short and compact code that does a lot. They're also impossible to read and maintain!
What I'd challenge you to do is find some short bit of code you've written that you think is particularly good, then play code golf to reduce its size. I can guarantee that you'll find plenty of redundancy in function of which you can take advantage to reduce the code size. I'll also guarantee you that your code will be less readable and far more difficult to maintain.
If you really are a born-again acronymist, you'll happily take DRY to its absurd conclusion and golf your way to an unmaintainable nightmare. My guess is that you'll quickly come to your senses and realize that DRY is really just a bit of folk wisdom. It's good to avoid a lot of redundancy (somethings things should be made more generic) but that it's not truy evil, and can sometimes be helpful. Particularly when it makes your code easier to read.
Speaking of making code generic, that's not always a good thing either. You've probably seem this yourself, where a programs size and complexity were dramatically increased by trying to make everything as generic as possible (usually justified as making the code 'reusable'). While a joke, FizzBuzz Enterprise Edition makes my case here nicely.
Keeping code simple and readable is far more important than any fly-by-night acronym you'll run across.
Required reading for internet skeptics
In a project I am currently working on we have started using the C# goto case "state" construct.
In this case it offers us a huge performance improvement as the state machine only executes one step when it receives a heartbeat from a piece of networked equipment. The heartbeat only comes in once a second and there are instances where we can perform more than one step of the state machine without needing a response from the remote equipment.
An example of this is uploading files to the remote equipment. We use a Web Socket to establish the transfer task, but once we start sending files (HTTP POST) we don't need a response from the remote equipment between each file. Prior to the use of the goto we could only send one file every second, now we can loop through all the files by looping with the goto.
This is a specific example, but does show that there are limited instances where the use of a goto can be well justified. I also always comment every use of non-standard behavior (use of goto)
Working in something new that interests developers is a good idea. Working in something that frustrates them and forces them to be on call is a bad idea. The trick is to balance the two.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
That is quite the opposite to what I have seen, most problems I see, appear that the person who wrote it doesn't know what a function is, the same piece of code is repeated 5 or six times. Inevitably as changes occur all the versions don't get maintained which leads to bugs.
Like anything, you have to take the rule with a grain of salt, like any rule. It is not always possible to not repeat yourself, so if you are going to break the rule then you should have a good reason for it.
Repeating yourself, can also be unclear to someone reading your code, since they have to examine both parts and work out the differences, if there are any.
I have spent many hours comparing 2 sections of code line by line only to find out it varies by one parameter.
In programming there is a best possible solution to the given problem. You can maximize memory usage and speed and any of a number of other variables to come to best answer. I use a scientific approach to achieve this. I set my metrics, I run my baseline tests, make my improvements and test again. I can then quantify my results.
There is no right answer in art. There is no possible quantification on quality. Beauty is truly in the eye of the beholder.
I'd argue the opposite. Programmers who call themselves artists are just glorifying their own work. These tend to be the people who don't understand the logical nature of their work. Not that it matters, but logic was one of my strongest subjects.
Additionally, your tag line isn't a real quote.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
Whether to go new or not should depend on how horrendous the old way of doing something was, AND how stable, well documented, and community supported the new thing is AND how many of the old way's fundamental problems/weaknesses the new thing solves.
It's not a simple decision, and needs to be made case by case.
What really matters is the quality of the technology and the community that is actively working with it, supporting it and improving it. Not the age.
Where are we going and why are we in a handbasket?
I have dealt with a number of DRY fanatics who seem to think perfect adherence to the acronym outweighs even having a program that does what it is supposed to do. People sometimes forget that their job is to solve problems rather than writing perfect programs.
I don't think the article suggests mysql over mongodb in all cases (maybe for the simple case). I think the main point is not to use both.
You got me into this! You were the ideologue! I'm only a poor assassin! - Twenty evocations, Bruce Sterling
In programming there is a best possible solution to the given problem.
Nonsense. Though that silly belief is a big part of the delusion.
There are a lot of factors to consider when writing a computer program. Some (but not all) of those factors can be quantified. How best to balance those is also deeply subjective. For example, is a fast program that uses little memory but is difficult to read and maintain better or worse than a fast program that uses more memory but is easy to read and maintain?
I don't know that I really need to explain this further. It's pretty obvious that there is no such thing as a "best possible solution" to a given programming problem. To believe otherwise is, quite simply, delusional.
Required reading for internet skeptics
Not if your metrics also include readability and maintainability, which mine do. To think there isn't a best possible solution, is delusional. Something like sonar can easily quantify your readability and adherence to coding standards. Thus you can use it as a metric.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
The primary purpose of code is to communicate ideas (algorithms) with other developers (humans) and secondly to communicate with machines. The "art" of programming is thus closer to writing good and update-able technical documentation than it is to math or engineering. It is user-interface-design where the the "user" is another programmer (or your future self).
Good code is ironically more about people than machines.
Table-ized A.I.
Something like sonar can easily quantify your readability and adherence to coding standards.
Okay, I'll play. What coding standards are necessary to achieve the "best possible solution" for a given problem? How were these determined?
If you'd rather: How can we determine that we've arrived at the "best possible solution"?
Required reading for internet skeptics
This is because problems in the real world (and especially in real time) are arbitrarily complex (and corresponding solutions are approximate) and not amenable to the clean set of prerequisites necessary to "solve" them using mathematical techniques.
In other words we don't get to work with perfectly spherical cows.
A bullet may have your name on it but splash damage is addressed "To whom it may concern."
State machines have long been considered good uses for "goto". Commenting its use is good, as well as commenting all non-standard code.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
The "religious hatred" for goto came from a very real problem: so-called "spaghetti code".
The older programming languages favored having all (or most) of the logic in one big source module. Use of goto to navigate around in a large module often resulted in a veritable maze of logic that was virtually impossible to make sense of or apply automated analysis to. It could get especially bad in languages that supported an assignable goto target.
Structured Programming was conceived as a solution to that. By limiting logic paths, the number of possible logic paths was reduced to more manageable proportions.
The problem with pure structured programming was that for exceptional cases, the nests of loops and conditions could themselves become unwieldy. This lead to such constructs as throw/catch where a sequence could be aborted and control transferred to a well-defined outer location. A thrown object is effectively a goto without the free-for-all that the old-fashioned vanilla gotos caused.
A related trouble source was in methods that had multiple entry and exit points. Again, it made possible logic flows difficult to predict. Most modern languages do not permit multiple entry points, and as long as there are ONLY multiple entry points or ONLY multiple exit points, the code becomes much easier to follow.
Personally, I favor a style where most of the early-exit logic is at the beginning of the function, thus filtering whether the main processing will be done. Anything that requires exit after normal processing has commenced usually rates a thrown exception.
The first two are very easy, percent code coverage of unit tests and percent of methods documented. As for additional standards, every language has its best practices.
We are a java shop and use most of the default settings in sonar for best practices. This includes minor things like magic numbers and constant/method naming conventions, all the way to critical errors like dead stores to variables and threading issues. Sonar then takes the number of errors weighted by severity and divides it by number of lines of code. This gives us a nice percentage of code compliance to the defined rules. The goal again is to make that 100%. We also modified a few of the standards in house. For example, we count if statements without brackets against you. That is more of a trivial one, but we as a group agreed it makes the code more readable when working on projects with several developers.
The best possible solution would have 100% code coverage of unit tests, be 100% documented, 100% rules compliance on top of being the fastest, lowest memory consuming solution possible.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
The best possible solution would have 100% code coverage of unit tests, be 100% documented, 100% rules compliance on top of being the fastest, lowest memory consuming solution possible.
How disappointing. At least you tried. How do you know that your solution is the fastest, lowest memory solution possible? How do you know that your "best practices" are really the "best" and that there aren't better options?
Since you mention it, how do you know that the language or platform selected is capable of producing the optimal solution? You mention using Java a good bit, so you know that you're already adding a lot of overhead and thus very unlikely to produce a mythical "best possible solution" given your performance and memory requirements.
See, there is no such thing as the "best possible solution". What you're describing is an "acceptable solution" given a set of constraints, many of which (like your silly "best practices" which change with incredible frequency) are just folk-wisdom. They're not scientific, mathematical, or objective in any way. Your other constraints (memory and speed) are impossible to meet as you can't tell if there is a faster solution that uses less memory.
Instead of trying to win an argument here, reflect a bit. Particularly on how readability factors in to your above criteria. Are those criteria subjective or objective? Can they be measured? Are you really measuring what you think you're measuring or do your methods merely quantify something you believe to be related? On things like memory and cycles, how do you know that they are as low as possible and that there aren't different approaches that you could use to minimize those?
Further, when you trade memory for speed or speed for readability how do you know that your decision will lead you closer to this alleged "best possible solution"?
Required reading for internet skeptics
Astronomy existed before telescopes, microbiology before microscopes, physics before particle accelerators. These are all just tools that increased measure-ability leading to a more accurate scientific approach. Things like sonar are an initial run at quantifying things like readability and rules compliance and they do a fantastic job.
You can predict with some degree of accuracy what a programs optimal efficiency would be, or did you miss that in your computer science classes? You are right that different languages/environments change the results, and while it adds a large layer of complexity it is still quantifiable. There is and will always be a "best possible solution." I work in an enterprise and not in research, so nothing I do will ever reach that point, but that doesn't prevent it from existing.
Lets take a quick look at the definition of science: systematic knowledge of the physical or material world gained through observation and experimentation. Everything I have said has revolved around this definition, observation and experimentation to gain understanding. Its as if you are intentionally being obtuse.
On the other side art: the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance. You don't do whats beautiful or appealing when coding. You do what is right. You don't right a recursive loop when you can do it in a normal loop, just because it looks prettier.
As for memory vs speed vs readability, you can weight requirements making them more or less important and there by altering the target optimal performance. Its simple math.
At this point you are either just a troll or are an incredibly incompetent coder. Do you honestly sit in dev meetings and when asked why you did something respond with "because its art man"?
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
The "religious hatred" for goto came from a very real problem: so-called "spaghetti code". ...
Mod this up.
The problem with classical GOTO was that it could go -anywhere-. And often did. Even error handling should not be able to do that, cleanup must be done.
If you don't program like the PHB and the Salesmen tell you, you -might- get fired. But if you do, either you -will- get fired or the company will go bust and you will lose your job anyway...
How about boring news?
We clearly need to get back on track. The source of this conflict:
In programming there is a best possible solution to the given problem.
You now know that this assertion is complete nonsense. That was my entire point. It's been made. You admit as much with nonsense like this:
As for memory vs speed vs readability, you can weight requirements making them more or less important and there by altering the target optimal performance.
Read that again: "altering the target optimal performance" The word "optimal" there loses all meaning. It should read as simply "target performance". There is either an optimal solution or there isn't. Why not just say "the best possible solution is whatever I say it is". It's more honest, and just as convincing!
On science, you give this silliness:
Lets take a quick look at the definition of science: systematic knowledge of the physical or material world gained through observation and experimentation.
Science is many things. You define science as a body of knowledge. Science can also be defined as a method of inquiry, as a community, and simply to mean 'the study of'. I expect middle-school kids to understand something that basic.
The "science" part of "computer science" is science in 'the study of' sense. As a discipline, it's essentially a branch of mathematics.
Do you honestly sit in dev meetings and when asked why you did something respond with "because its art man"?
You also don't seem to understand what is meant by 'art'. I'm going to guess you're an autodidact. Am I right? I can't imagine that an educated person would make such an absurd statement.
Required reading for internet skeptics
I've actually used a goto where it wasn't harmful, but was in fact the simplest and clearest way to get from point a to point b.
Star Trek transporters are just 3d printers.
No, it's not science. (It doesn't even remotely resemble science!) Neither is it an application of science, for obvious reasons.
By all of the definitions you provided, programming is a science. The definition I chose was the harder to qualify for.
Take this example: Given a car with fuel efficiency x and distance y, you need to get the car to y. If I say time is your top objective, you'd just ignore fuel consumption and dive all out. If I tell you your goal is to get there the most efficient way possible, then time and fuel come into play. Your bashing of weighted variables just shows your ignorance in both math and science.
Since you clearly have a different definition of art why don't you explain it to me and why your code is worthy of such a title?
Not that you need to know my qualifications. I not only have a formal background in programming but am also an autodidact. I am a professional programmer with a good size company and I continue to take courses and work on personal projects in my spare time.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
Your bashing of weighted variables just shows your ignorance in both math and science.
That you need to make trade-offs, balancing both quantitative and qualitative variables, should indicate to you that the entire concept of a "best possible solution" is absurd. Revisit my earlier posts for more detail. We've been over this already. I can only repeat myself so many times.
All you've told me is that you can produce a solution that meets some requirements. That's not in dispute. Nor is it terribly interesting. We're after the mythical "best possible solution" you've been on about.
On math, science, and art:
Yes, you use math in development, but that does not make programming mathematics any more so than carpentry! Equally, while you may use some of the methods associated with science in programming, that does not make programming a science any more than auto repair, which also employees those same methods.
Both of those are examples of skilled trades. The largest distinctions between those and programming are the cultural assumptions we apply to their practitioners. I suspect that the social advantages afforded computer programmers is what leads to that delusional thinking.
When I refer to programming as an 'art' I mean that in the sense that programming is a skilled craft. From the preface to Knuth's The Art of Computer Programming:
The process of preparing programs for a digital computer is especially attractive because it not only can be economically and scientifically rewarding, it can also be an aesthetic experience much like composing poetry or music. This book is the first volume of a seven-volume set of books that has been designed to train the reader in the various skills which go into a programmer's craft.
I'm not offering a unique perspective here, but one long-established. It's frustrating to the neopositivists, but they also want to see programming become more like engineering. In that sense, even they acknowledge the nature of computer programming, despite their otherwise delusional thinking.
Not that you need to know my qualifications
It's just a game, for fun. I'm going to guess "2-year trade school" given that you claim a "formal background in programming" because I can't see that meaning anything else.
Required reading for internet skeptics
balancing both quantitative and qualitative variables, should indicate to you that the entire concept of a "best possible solution" is absurd
Just because you don't know how to do it, doesn't make it impossible or wrong.
especially attractive because it not only can be economically and scientifically rewarding
You destroyed your own argument.
When I refer to programming as an 'art' I mean that in the sense that programming is a skilled craft.
By that definition, everything is art. Even my original statement, the quote from breaking bad, is invalid. Life is art. Pumping septic tanks is art. At that point, whats the point of even using the word?
I'm going to guess "2-year trade school" given that you claim a "formal background in programming" because I can't see that meaning anything else.
Try more formal university level education. I was being modest and only brought it up because of your continuing slight against my intelligence and qualifications on the subject. Honestly, I have no doubt I am a better programmer than you. You would look upon my work and consider it art.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
Just because you don't know how to do it, doesn't make it impossible or wrong.
It's wrong in principle. As you can see from your own explanations, you don't know how it can be done either. The reason, of course, is that it's a complete absurdity.
Again, it seems that you've confused 'a solution that meets the requirements' with 'the best possible solution'. I'm not sure if you're actually still confused, or just too ashamed to admit that you misread my original post.
You destroyed your own argument.
By financially and scientifically rewarding, Knuth is referring to the benefits of computer programs to science and industry.
This isn't ambiguous. I'd suspect that you're being intentionally obtuse, but I can't give you that much credit.
By that definition, everything is art.
You think everything is a skilled craft? I'm sorry, I must simply disagree with you outright as I can't comprehend the confusion of ideas that would provoke such a response. All I can do is direct you to the nearest dictionary. You can write an angry letter to the publisher if you're still having trouble.
I was being modest and only brought it up because of your continuing slight against my intelligence and qualifications on the subject.
I thought I was being rather nice, considering what you've offered here. I had you pegged as a trade-school dropout after your impossibly incompetent reading of the Knuth quote. Just look at your own posts. They are clearly not the product of an educated person!
Required reading for internet skeptics