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."

Comments

A Corollary for Code

[Dutch Gun]

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.

Re: A Corollary for Code

[nine-times]

I'm not a programmer, but more in IT support, and but it seems like there's always someone doing the same thing: trying to be clever. Everyone wants to be a cowboy. Everyone wants to do something badass that serves their ego.

more often than not, doing a good job is more about paying attention, being thorough, and doing the obvious thing. Listen to the user, read the error messages, look in the relevant log file. Tell the user what to expect, and then keep them informed until the problem is resolved.

I wonder if that's that it's about in all professions. Maybe most jobs don't require special genius, but most of the secret is just being thorough and conscientious, and using some common sense.

Re:A Corollary for Code

[readin]

I was recently explaining to some students why I don't know about the trickier parts of the language I use everyday. I don't use those tricky parts and I would chew out anyone on my team who did, so the precise details of how those parts work never come up..

Re: A Corollary for Code

[tnk1]

There is a lot of flash these days in coding. Someone is always trying to sell their wares to a venture capitalist. To do this, you have two options.

First, you can write a stable application in something boring and then develop a track record of excellent service underlying an elegant and interesting design that serves a purpose that can make a profit. This actually does get attention, but not as commonly as....

Secondly, you come up with some glitzy idea, and attract elite developers who really want to do whatever the hell strikes their fancy. This works... mostly because they really are elite developers, and their team is young and motivated. They can use some random bleeding edge idea because they are good enough to make it work, and they may have even had a hand in developing the new ideas personally. When that fails, they are willing to work like coke addicts to get it done to a point where it can be sold.

There is nothing inherently wrong with either option that rehab won't solve.

The real problem is when everyone else tries to be like the people in the second example, when what they really need is to be the people in the first example.

Look into a mirror and stare at yourself for a minute. You're competent, maybe even excellent at your job as a developer. Your team is solid. You're just not that kind of elite, however. You dearly love the flashy stuff, but you don't quite understand it as well as you'd like. Instead, you've been working in X technology for a number of years. You know how it works and so does your team. You have a track record of success. Boring, but successful.

You need to be a professional and understand your limitations. If you do, you will be part of a team that makes things happen. If you don't, you're going to make a mess. Don't pick sexy unless you really have what it takes to back it up. That is all.

Re:A Corollary for Code

[Anonymous Coward]

I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.

Unless you are talking about REPRODUCTIVE choice. Hypocrite...

Re: A Corollary for Code

[Anonymous Coward]

Also, like being sexy, be sensitive of how you age... some can do it, some cannot. I was clearly in your second group a few years back... now that I'm getting older, value sleep, try to avoid the hypertension that was destroying my heart, have to manage other people that also code... being in the first group is fine.

Re:A Corollary for Code

[dargaud]

A former boss once told me: "Whenever you think of a clever programming trick: forget it !". At the time I thought it was a joke, but now with experience I see the wisdom of that.

Re:A Corollary for Code

[91degrees]

Absolutely agree with that. Some of the horrors I've seen include everything is a singleton, virtual methods replaced with templates, a complete reimplementation of std::map and std::vector, with map implemented as a vector of key/value pairs (Yes - seriously; they had O(n) access time). Actualy, that last one was all about reinventing the wheel. A reinvention of string class (where we already use 3 standard-ish implementations).

The nicer projects use standard types, base the architecture on existing successful products, and have a fairly simple class heirarchy.

Re:A Corollary for Code

[Anonymous Coward]

For pretty much every tricky language feature, design pattern, complex algorithm etc you'll run into, there exists a project that uses it correctly and gains significantly from that. The problem is that there are so many of them that you cannot expect to be able to master them all no matter how good you think you are. A good developer understands this balance while bad developers go to either extreme.

Re:A Corollary for Code

[jellomizer]

"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?"

I wouldn't be so judgmental on that. You may not know the details on what they are trying to accomplish. What I really hate are respondes to those question admonishing the person for doing it wrong. Then tell them to do it in a way that they stated wouldn't work for their use case.
If the question is posed then they may be faced with an interesting challange, that is outside of the given language core compenancy, for the one particular instance. The official stance may not perform up to snuff, or have that one little peace in it that will prevent you from getting what needs to be done.

Re:A Corollary for Code

[Karmashock]

Valid for okay programmers. The great ones don't need to draw within the lines. You don't innovate by hashing together someone else's crap.

Re:A Corollary for Code

[TheRaven64]

Not knowing about trickier parts of a language doesn't mean that you don't use them. I recently discovered some code where experienced C programmers didn't know that signed integer overflow was undefined in C. This meant that the compiler could optimise one of their tests away in a loop (nontrivially, in a way that's difficult to generate a warning for) and turn it into an infinite loop. After a few weeks, their code would hit this case and infinite loop and freeze. Unless you know that this tricky part of the language exists, you don't know enough to avoid using it.

Re:A Corollary for Code

[Anonymous Coward]

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan

Re:A Corollary for Code

[Anonymous Coward]

The thing that gets you is the assumptions. Say you build a network (that's my speciality) and you make an assumption that your customers will not need data outside of the data center.

The minute you build a complex network methodology that delivers real speed and latency improvements to the customer for edge to data center transactions, you'll find that someone needs edge-to-edge connectivity. And in some cases, providing that connectivity will either be close to impossible (region based firewalling, non clustered, routing etc) or the perceived speed (latency + bw) is so horrible that it's unusable.

Re: A Corollary for Code

[qpqp]

I was clearly in your second group a few years back...

Maybe you just were not sexy enough, hm?

Re:A Corollary for Code

[smooth wombat]

which often makes for horribly unintuitive or unnecessarily complex systems.

Indeed. Witness the unmitigated mess which are today's web pages, filled with mountains of complex code creating unintuitive navigation and unnecessarily complex layouts.

KISS has officially been abandoned in favor of crazy language tricks just because the programmer could.

Re:A Corollary for Code

[syn3rg]

And we all know what the failure mode of clever is....

Re: A Corollary for Code

[gmhowell]

I was clearly in your second group a few years back...

Maybe you just were not sexy enough, hm?

I'm too sexy for my hat, what do you think about that?

Re:A Corollary for Code

[readin]

True, but sadly ( I do miss C sometimes) I'm not using a language that has those kind of gotchas.

Re:A Corollary for Code

[dave420]

So you don't know about something, yet assume you know enough to know it's not useful? And you'd chew someone out who found a great way to achieve something because you think it's using tricky parts of the language, parts you are intentionally ignorant of because of some unmentioned reason?

You don't sound particularly rational. I could make a joke about your sig, but I'll leave that alone.

Re:A Corollary for Code

[readin]

I'm surprised to learn that it is undefined. I thought it always just rolled around.

Re: A Corollary for Code

[pr0fessor]

I used to spend a lot of time answering questions that people simply had not taken the time to think through and usually didn't have all the information they needed to make a conclusion. The ability to approach varied problems in a logical manner probably is a special kind of genius.

Re:A Corollary for Code

[Anonymous Coward]

The problem is that boring doesn't always translate into good pay or security. The reason most developers try to be on the cutting edge is to take advantage of the opportunity being a cutting edge programmer gives you. I may not have wanted to learn the latest framework from so-and-so, but the hot project at my company uses it and if I don't want to be stuck in support or fixing bugs, I better know that new framework. Worse, if I don't learn that new framework, eventually the only way I can learn it is by maintaining someone else's code (As we all know, real coders maintain code. Hacks develop it).

So if you plan to be an employee for a company, you may be happy writing boring code, but you may also be replaced with someone who knows nothing about the system you maintained, but knows X. Then you have to learn the new framework anyway, but only learning it from maintaining it.

Re:A Corollary for Code

[Anonymous Coward]

Yeah. I would've thought rolling around was 100% necessary for a -1 plus a +1, all repesented in two's complement, to equal +0.

I dunno, maybe because that stuff happens on the CPU doesn't necessarily mean it's bound to happen in C.

(And of course, x + (-x) == 0 is the very definition of a negative number, at least in maths.)

Re:A Corollary for Code

[david_thornley]

Back when dmr was designing C, the variety of computers and CPUs was much greater than we have today. Given arithmetic, some CPUs would raise some sort of exception or fault, some would wrap, and very possibly some just returned (perhaps unpredictable) garbage of some sort. For C to be usable as he intended, there had to be a way to reliably compile some form of arithmetic to efficient machine code, and if dmr specified some particular result any compiler for a CPU that didn't act as he said would have to do expensive range checking for normal arithmetic. (Unsigned arithmetic was well defined, and presumably had to be emulated on some CPUs.) Hence, signed arithmetic overflow was undefined.

Personally, I think implementation-defined would have been a better choice, but that might have caused problems on some odd CPUs that returned unpredictable garbage. Nowadays, almost all computers just wrap on arithmetic overflow, so it's a real surprise to find it's undefined.

Re:A Corollary for Code

[Anonymous Coward]

What are you using? Scratch?

Re:A Corollary for Code

[david_thornley]

What I really hate is people asking how to do certain apparently stupid things without explaining why they can't do things the normal way. In my Stack Overflow experience, many of those people are really asking something stupid, and if they'd just tell us what they're trying to do we could come up with a good way to do what they really want. If they'd just say they have a measured performance problem, or they need something slightly different, they'd get a good answer pretty fast.

Re:A Corollary for Code

[Anonymous Coward]

More than "boring tokens" these are "dependency tokens". Dependencies are the root of all evil since too many of them will find you playing daily whack-a-mole. They're also "intellect tokens" since you'll need a higher calibre/more experienced programmer to deal with them all. They're also "sanity tokens" since your devs will grow tired of too much technology burden and start leaving. That creates brain-drain and it's the death knell of the project.

Observe the KISS principle. Don't write stuff that's already been written, unless the offerings are of low quality. Don't accept frameworks that promise the world and force you to sign your life away to a 1.5GB DLL. Tomorrow that DLL won't be built for your architecture and then you're SOL. Only use toolsets that deliver multi-platform compatibility. We live in a multi-platform world now...embrace it. At least multi-platform designers know the challenges here, and there are a lot of them. If you're prepared to accept the license then consider an open-source software stack which gives you the most flexibility. If you do this then, still, remain wary of low-quality offerings. You don't want to unknowingly become the beta-tester for someone that stopped giving a shit about their codebase 5 years ago.

But, yes, complexity is rife and everyone likes to show off a little. Someday that showing off will land you in a motorcycle wreck and you can only jump through so many fire rings wearing a suit of TNT before something bad happens. Playing safe isn't sexy, but you might live to see another day. If you must play risky then observe the golden rule "never put the prototype into production"...it's the ultimate prophylactic of the software world. When you write a prototype you start from the perspective of not counting the tokens, because you don't believe it will work and will last 3 months. Once you prove that it can work you have to throw away "and now count the tokens". If you don't you'll start the game already bankrupt.

Re:A Corollary for Code

[Zordak]

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.

Unless you're Mel, in which case you make awesomely unintuitive and necessarily complex systems to save one or two clock cycles in the inner loop, and become a legend.

Re:A Corollary for Code

[Dutch Gun]

Yep, this is at the heart of the "write boring code" rule. This also includes extending and enhancing previously created functionality as well. It also leads to another consequence in my own code: You can typically measure the complexity of the code by looking at the ratio of code to comments.

In most cases, when the code starts getting really complex (sometimes it's impossible to avoid), I start writing paragraphs instead of single line comments. When you see multiple paragraphs, you know you're dealing with some really tricky code that I undoubtedly wished I could have drastically simplified, but failed to do so.

Re:A Corollary for Code

[Anonymous Coward]

Negative numbers are just negative numbers and C doesn't really care whether it's two's complement, ones complement, sign+magnitude or whatever. These "roll around" quite differently, but follow math as long as you don't overflow.

What's meant by rolling around is eg. that 2147483647+1 = -2147483648.

Re:A Corollary for Code

[Dieselsauce]

You sound like one of those types of managers who surrounds herself with more stupid versions of herself. The other type of manager is one who surrounds herself with staff who excel in areas she lacks.

Good thing you're professing now. It's probably a hell of a lot easier to deal with those students who excel in the areas in which you lack than it would be to deal with employees possessing the same.

Sorry to castrate you. I can understand why someone lacking the mental capacity would not deal with the tricky parts of a language. But to erect the same barriers on your staff who may not be so limited, unless as explained above you surrounded yourself with more stupid versions of yourself, makes no logical sense.

Re: A Corollary for Code

[nine-times]

Agreed. I'm definitely not saying that there are no genuine brilliant "rock-stars" in these fields. Even in my field, boring old network/desktop support, every once in a while you find someone who just seems to be really good at diagnosing problems quickly, making intuitive leaps to conclusions that frequently turn out to be correct, or quickly assessing which risks to take. There are also people who are kind of amazing at dealing with users/customers, where someone will call in completely and justifiably pissed off, and the tech will listen and talk to them, and in the end the caller is satisfied.

Those people may have, to some extent, earned the right to "be a cowboy". However, the people who have earned that right are much more rare than the people who think that they have. And what's more, those people would often do better to color within the lines most of the time, and save "being a cowboy" for the relatively rare situations where it'll pay off. Sorry if I'm mixing metaphors.

So my point here is, even with those young, smart, motivated programmers who are working like coke-addicts, they might be making some big strides and getting a lot of things done. Still, at some point you want to take that flashy application and make it stable and reliable, and then a bunch of coke-addicted cowboys aren't going to succeed.

Re:A Corollary for Code

[lucien86]

Great advice. But I am writing a Strong AI. I was caught on the ass end of what felt like every ugly crazy language trick that C++ was capable of. Yes it was ugly, boy was it unintuitive, oh god.. there were single variable name calls that were more than a whole line long and had something like seven layers of indirection.

Then I realized that I was trying to build an egg using a spanner, and it didn't work. Once I realized that I needed to rewrite the heap system and core memory management things became easier because I realized that it was all just impossible. In the end the solution turned into FPGA and Verilog..

You cant imagine how much I sometimes wish for 'boring' code.. Back to the bleeding Edge. :)

Re:A Corollary for Code

[gzuckier]

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan

90% of debugging is finding the missing semicolon. if i've written something unusual, i've in all probability examined it thoroughly when i designed it.

Absolutely

[rjstanford]

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.

Re:Absolutely

[Anonymous Coward]

What?

Re:Absolutely

[Anonymous Coward]

Mass market CRM systems are like cheap off the rack suits. They can be cut and altered in a limited way, but in the end they tend to be a poor fit for you individual business. Compare that with a well crafted custom system where the fit and finish are perfect and you have the feeling of a bespoke suit, made to fit you perfectly, where every detail supports and compliments your way of doing business instead of crimping your style or getting in the way.

Re:Absolutely

[gl4ss]

umm yeah?

no. the article tries to argue that you should choose lotus as your crm, because you already used your innovation tokens on node.js, nginx and amazon s3 and now you have to wait 3 years to choose something else that's innovative - so you're also stuck on using exchange as the mail server for the time being and can just forget about targetting chrome in your product because that's too fucking innovative.

Re:Absolutely

[tnk1]

Maybe it *is* too innovative.

Its not a matter of Lotus being good. Its a matter of what you can do with limited resources.

If Lotus Notes (shudder) is working for you at the moment, and you really, truly needed to move to node.js, nginx and S3 for some reason, then you need to weigh all the effort that goes into making all of those as stable as you need them to be in order for them to be an actual improvement.

New things need not only code, but tests. If they go into production, they need the operations team to know how to tell if something is wrong with them, and how to fix it. Preferably without waking you up at 4am each time. More preferably with them able to proactively watch for signs of imminent failure and deal with it well before it becomes an issue.

All of that sort of understanding is more than just what it takes to check in some code and some unit tests.

The realistic situation in your scenario is a little backwards because I don't know of any reason to switch to the other three techs without putting Lotus Notes out of its misery first. There does need to be a realistic understanding of priority. What is not-so-good and what is a complete clusterfuck, like Notes.

You can't do everything you want. If you try, you're going to create problems unless you can increase resources. If you can't increase resources, you need to wait.

Re:Absolutely

[rjstanford]

Yes, and I'm actually on board with that (although I'd have picked Salesforce if I'm just blind-picking out of a hat).

If you're just the average 20-80 person software shop - somehow refusing to believe that the (literally) millions of businesses running on platforms like Lotus Notes or Salesforce are doing alright and that your business is so terribly revolutionary that its better to spend hundreds of hours deciding-on, deploying, customizing, and supporting your own specialized CRM is a better use of your organizations time than spending those hundreds of hours on making better products and selling them to people for money, well then, I suggest that you're part of the problem.

Re:Absolutely

[Anonymous Coward]

Custom tailored suits, however, are significantly more expensive. Most clients have off-the-rack budgets.

Re:Absolutely

[bluefoxlucid]

The article is meaningless bullshit.

I evaluate things I use. When MongoDB came out, I told our dev manager we should use it because we are storing flexible, complex data in MySQL and that's just not a good fit. Document stores are better, and MongoDB with acknowledged write mode in a 3-node replica set has roughly the same data consistency guarantees as PostgreSQL with a replicated WAL in the common async mode (there's a small window where the slave server may crash, and the master server may also immediately crash, and the very last few milliseconds of transactions are lost; on MongoDB, the same happens if the first replica node acks an update, the update never reaches the second replica node, and the first replica and the current primary crash immediately).

At the time, we were handling schemaless documents by creating tables in MySQL with rows that described other tables, and using incremental joins to assemble fields from hundreds of tables together to select individual documents. What is a single document collection and a quick find() in MongoDB is any combination of dozens or hundreds of tables in MySQL, accessed with complicated aggregation logic to select information about these tables and then select and join together data from them to build one document at a time. MySQL wasn't intended to store documents consisting of a number of standard fields followed by arbitrary structures of searchable, user-defined fields; MongoDB was.

The article suggests using these types of psychotic schemas in MySQL to avoid innovating by taking MongoDB up. It suggests using Apache and built-in CGI rather than nginx and an external application (WSGI+python, a Perl CGI application manager, php5-fpm, etc.). It suggests sticking to Perl or PHP instead of Python and Cherrypy. It suggests, by extension backwards, sticking to IIS5 instead of moving on to IIS6 or a Linux server.

The article ludicrously suggests not even evaluating new tools and using those which make your work better, faster, lower-risk, more consistent, less likely to fuck off in your face; it recommends you run scared from all the new things. Maybe you should learn risk management and get a good enough handle on your technical and business needs to evaluate new technology and decide which you can use effectively and which you should hold back on.

Re:Absolutely

[gl4ss]

that's not the point!

the point was that because your company used innovation tokens already then you need to stick to something old, leading to situation where you would use access 2000 to store data shown by a web front end generated by node.js, just because "well, can't have too much new stuff".

Re:Absolutely

[rjstanford]

And indeed, when MongoDB first came out it had all sorts of issues living in production environments. Now, on the other hand, its well-understood, the serious bugs are fixed, and its ready for casual users. How long would it have taken you to get everyone (including dev-ops) up to speed on MongoDB as opposed to actually building product over MySQL until (as it is today) a competitive solution was stable and "boring" enough?

If handling data elegantly is your company's selling point, then maybe its worth innovating on your storage engines and being on the "bleeding edge". If that's the case though, the article is suggesting that you don't simultaneously innovate in your development language, source-code storage system, and business model. That's all.

Re:Absolutely

[bluefoxlucid]

How long would it have taken you to get everyone (including dev-ops) up to speed on MongoDB as opposed to actually building product over MySQL until (as it is today) a competitive solution was stable and "boring" enough?

The solution developed on top of MySQL started about 11 years prior to our switching from MongoDB. It never worked. It changed hands to a new rockstar developer who, over 14 more months, rewrote the code in 1/3 as many lines and got it semi-working, but it was academic: it could perform the task, but it was slow and clunky and impossible to maintain as a code base. When I installed MongoDB, they spent a month looking at it, and had a working prototype in 6 weeks; 2 months later, they released two entire new projects built on MongoDB to address both the things the first, failed project tried to address and an entirely new requirement.

MongoDB was considered fresh and new around version 2.2, still. It was being talked about and criticized even though 2.2 was deep into its maturity. Similarly, Linux was considered a new product around version 2.4; it was in production in version 2.2, and RedHat was happily chugging along, but it wasn't a cultural revolution in the IT industry until later than that. Scarcely before MongoDB, there was CouchDB and CouchBase, which most people are only aware of academically.

I jumped on MongoDB when it was this thing that some people had leveraged successfully and most people believed was a brand new fad that would go away just like everything else that tried to replace SQL over the past 20 years. MongoDB doesn't replace SQL; it does something different.

the article is suggesting that you don't simultaneously innovate in your development language, source-code storage system, and business model. That's all.

In a year's time, we moved from a dev team of 2 and SVN to a dev team of 4 and Git; we moved from raw SQL to ORM; and we incorporated MongoDB into our applications where appropriate. We also moved onto a cluster system with GFS2, which was successful, but badly mishandled: I didn't want the security implications of logging into the internal LAN's vmware vSphere management panel from internet-facing Web servers, and management didn't want to build a DMZ VMware farm, so we used sanlock fencing. Never use sanlock fencing. If we had built the cluster properly, it would have been a reverberating success capable of handling all kinds of disruption without the slightest hitch. I made all the correct assessments, but we decided as a business to go about it the wrong way; I conceded, and my lack of knowledge prevented me from predicting just how bad these concessions would be.

Three huge steps forward, three huge gains. One other huge step forward, done in ways recommended against, with good gains, but with growing pains; and even that moderate failure was both still a major success and readily avoidable in foresight, with the nebulous problem of "this could cause additional issues in some unknown situations" being correct, if unspecific. I know about black swans, I knew they were out there, didn't know what they looked like, but knew how to avoid them; unfortunately, I didn't take the steps to avoid them, and found out what they look like.

Re:Absolutely

[MobyDisk]

I think you meant "should NOT be trying to" then the rest follows logically.

Re:Absolutely

[clam666]

Would that be a schtickle of schemaless?

Re:Absolutely

[bluefoxlucid]

Everything organized has some method of organization. People talk about schemaless documents, but they arrange them into related collections which carry some common features.

Re:Absolutely

[david_thornley]

I understood it as saying that most shops have limited facilities to support new stuff that isn't really predictable, and so it's important to know when to be boring and when to be innovative.

If you're running production on software you don't really understand, it's going to take a lot of work and commitment, and people are going to get called in at very inconvenient times. This is fine when there's real advantages to be had to offset all the extra costs, but most shops simply can't do this for many different things, so getting too innovative will cost too much and put too much stress on the staff. The idea of "innovation tokens" is one way of explaining this.

Therefore, it isn't a matter of not moving from Exchange because of an arbitrary limit on innovation tokens, it's a matter of not moving from exchange because your best people are fully committed to supporting bleeding-edge software. (BTW, why move from Exchange? Like most Microsoft software, it does a good enough job for most things, and people are used to it. What's so much better than Exchange that it's worth changing, and why?)

Re:Absolutely

[david_thornley]

There's no model of management of planning that can't be screwed up. If the CIO is gung-ho to put new technologies on his or her resume, to the detriment of other things the company needs more, that sucks for the company and the people who work there. It doesn't mean that throwing more and more resources at the CIO is the right thing to do (although it seems to be a fairly common practice).

No one ever got fired for buying IBM

[TWX]

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.

Re:No one ever got fired for buying IBM

[Puff_Of_Hot_Air]

Mature technologies are proven.

Yes, but somebody had to do the proving. As that great fount of wisdom, John Wooden, once said; when we are young we tend to see all change as progress, but as we mature, we can forget that there is no progress without change. It's not easy to know when you should take on a new technology, but that doesn't mean you shouldn't take on a new technology.

Re:No one ever got fired for buying IBM

[Anonymous Coward]

It's not just NodeJS. NodeJS 0.12 came out and broke a ton of dependencies that worked fine in 0.10.

The change? Well, it turns out that V8 itself (the JavaScript engine NodeJS uses) is not a stable technology and Google had incompatibly changed it sometime between the version NodeJS 0.10 uses and the version NodeJS 0.12 uses. Thereby breaking any code anywhere that had any dependency on native code, which given how limited NodeJS's core library is turns out to be "almost everything, somewhere."

So not only do you have to worry about random halfassed changes from NodeJS, you also have to worry about Google breaking everything when NodeJS is forced to upgrade or lose out on continued V8 development. Including, potentially, security fixes.

So, yeah, boring is great. There's nothing like pulling a five year old code base and discovering it can only work on a single point release of the language it was written in because the language "evolved" in backwards incompatible ways. (Why, yes, I would be describing a project I'm working on now, but the flavor of the month five years ago was Ruby on Rails. Same concept applies, though...)

Re:No one ever got fired for buying IBM

[Dragon Bait]

It's not easy to know when you should take on a new technology, but that doesn't mean you shouldn't take on a new technology.

And when you consistently refuse to take on new technologies, that's when the countdown to obsolescence has begun.

Re:No one ever got fired for buying IBM

[tnk1]

There has to be a balance. You need to move forward, but don't just change to change. The article suggested one method of moving forward while remaining stable.

I understand as well as anyone that the world moves and sometimes even perfectly functional applications need to move with it, despite the fact that nothing is wrong with them. There are end-of-life issues with hardware. The code has gone missing. Customer support shuttered ten years ago. You have one greybeard who knows how to operate or make any changes to the app, etc.

That said, there's a lot of stuff out there that is seen as "old" which is still fully supported and stable. It is getting security updates. It can handle large scale deployments. It is free and open source, &etc. You don't have to move away from that. You probably *shouldn't* move away from that.

Fashions in development don't always require you to have followed the path all the way to the endpoint. You holding back now might mean that you can jump ahead two steps when the turn for the next component comes up. You don't need to track the curve constantly to be able to join everyone at the innovative end after a hop.

Most of this stuff is a fad that will add more flash than actual feature set. Wait for two fads to pass and you might now have a real set of features to sink your teeth into. And in the meantime, you have had a stable and well supported application to build on.

Re:No one ever got fired for buying IBM

[Dragon Bait]

There has to be a balance.

I think you and I are in complete agreement across the board. I would mod you up.

Not every new technology that comes along is worth knowing. It might be worth learning, but that doesn't mean it's worth knowing.

As a developer, you have to update your skills along the way, if for no other reason to keep you ability to learn and improve going. I've seen too many times where we've had an inflection point (e.g., moving from Fortran to OO) and you can see it in the eyes one of the developers: I'm not going to make this transition. At that point, their useful life as a developer are numbered.

But that doesn't mean you should constantly jump to the latest buzz. You'll never actually produce something lasting if you don't have a solid foundation of things that work.

Re:No one ever got fired for buying IBM

[countach]

COBOL, Fortran etc work, but not well for large projects. You can't work around it when you have a million lines of unmaintainable code.

Re:No one ever got fired for buying IBM

[gbjbaanb]

Yes, but somebody had to do the proving

somebody else can do it - somebody who isn't trying to make a product that will last. Startup type people who will bang something out and then, if it proves successful, rewrite it in boring technologies anyway.

I think the simplest way is just to use boring technologies anyway, if you consider anything that has been around for a few years becomes either old and boring, or dead and unused.

Re:No one ever got fired for buying IBM

[Anonymous Coward]

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.

One of the main things I like about being an actual engineer these days rather than a software "engineer", it's much more relaxing applying technologies that have been proven and don't change every year or two.

Re:No one ever got fired for buying IBM

[Fnord666]

somebody else can do it - somebody who isn't trying to make a product that will last. Startup type people who will bang something out and then, if it proves successful, rewrite it in boring technologies anyway.

Startup types will use whatever technology lets them shortcut their way to being first to market. Once it's up and running they move on to the next startup and leave it to the new owners to figure out how to implement it using a boring technology that will actually scale and be a viable business.

Re:No one ever got fired for buying IBM

[Anonymous Coward]

Right. Companies buy mainframes to play Tetris

Re:No one ever got fired for buying IBM

[H0p313ss]

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.

I'm not disagreeing with you, but I thought you'd find it funny to know that IBM is now building products with NodeJS. (And other even more exotic bleeding edge stuff...)

Re:No one ever got fired for buying IBM

[david_thornley]

COBOL is an excellent language for certain big dumb projects. (I really don't want to do COBOL, but that's partly because I really don't want to work on that kind of project.) Moving such a project to Java has a nonzero chance of making it more expensive to run a less capable and much less reliable system intended to do the same thing. (This particular statement has been empirically verified.)

Re:No one ever got fired for buying IBM

[TWX]

Huge technical companies used to run incubator programs in-house to do this kind of development. Most of our now-stable development tools and platforms originated in just such incubators. Palo Alto, Bell Labs, IBM Research, all paved the way for robust tech without forcing it on the public before it had at least been Alpha-tested.

Now Alpha versions are released as something to try to use, and Beta versions are sold. That's just not right.

Re:No one ever got fired for buying IBM

[Anonymous Coward]

Few programmers even understand their outbound edges - many a project has been developed oblivious to what 3rd party components it's using (much to the chagrin of the legal department).

Even fewer programmers appreciate inbound edges - "the people that depend on YOU".

But sure, rename all your methods. It's not like you're costing 100s of thousands of development teams time to recreate your artistic twitch.

Plain old boring rules

[El_Oscuro]

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.

Re:Plain old boring rules

[Anonymous Coward]

Oracle isn't exactly the most cost effective solution as a back end for a web server.

However, if someone is already footing the bill for it, then sure.

There are cheaper but still simple solutions than the Oracle rape train, though.

Re:Plain old boring rules

[Anonymous Coward]

Did you miss the part about it being an open source apache mod? I think that was his entire point even. I guess you gotta hit your talking points somehow though. amirite?

Re:Plain old boring rules

[Anonymous Coward]

Oracle is totally incomptetent regarding UI's. However, as long as you recognize that (and stay away from tools that would imply otherwise), it's entirely possible to write a working web application in pl/sql, with nonlinear navigation and all (amazing, I know). These days the result might be a little bit more spartan and server-sidey than what worst html5-weenies expect, but still working.

Re:Plain old boring rules

[Dr_Barnowl]

It might be an open-source mod for Apache, but it's backed by an Oracle database. It only issues PL/SQL calls, so you can't just slap in another RDBMS.

Oracle costs some serious money.

Re:Plain old boring rules

[dwpro]

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.

Ah yes, the beauty of non-version controlled code stored as giant strings in the bowels of a database with the most powerful of languages (pl/sql, of course) to grease the gears. I bet it's a complete joy to use.

Re:Plain old boring rules

[tomhath]

Why would you not version control the code? It's deployed to the server, same as deploying any other code. As far as pl/sql, it beats the heck out of writing applications in XML

Re:Plain old boring rules

[new_01]

It's entirely within reason to version control their sprocs. Think of the database as a deployment, not the storage mechanism for code.

Re:Plain old boring rules

[Anonymous Coward]

I'm not even sure you actually read the three lines of that post.

If someone already has Oracle, and you need a webserver, then its free for to to use something like mod_owa.

If you want to use mod_owa, but you don't already have Oracle, then you now have the opposite of affordable if you now need to buy any version of Oracle to back-end it.

Either way, it is probably not a solution that you can use generally.

Re:Plain old boring rules

[Anonymous Coward]

How about a link to this website? It must be fairly basic if all of the logic is contained within the database layer in pl/sql code or you are leaving at some critical technologies also used to make the website function. There is a reason why the solution you are advocating is not championed more often.

Re:Plain old boring rules

[dwpro]

True, you can version control the stored procedures. I don't think that takes away from my point though, pl/sl is a horrid language to write advanced business logic and I'd wager more than a little business logic is tucked away in the rows that store the "data". In peoplesoft's horrid incantation I worked on 7 years ago, there are large strings of javascript and html containing non-trivial extensions to business logic, just sitting around in rows. Try code reviewing that mess.

Writing your own database

[Anonymous Coward]

A buddy of mine wrote his own database completely in windows command line through the very extensive use of for loops and a ton of windows command line modules that he built from scratch. At least he made a module where data could be exported to csv.

Re:Writing your own database

[Anonymous Coward]

"A buddy of mine"? - have you been binge-watching "Pawn Stars" again...?

Re:Writing your own database

[Anonymous Coward]

Was it ACID compliant or was he just on acid?

Why? About the only good reason I could think of is "to see if I could do it" - and even that reason isn't very good in this case. It might be interesting to figure out if you could perform delicate brain surgery with a Leatherman multi-tool but not so interesting to figure out if you can perform the same surgery with a hand grenade and some duct tape.

Re:Writing your own database

[silentcoder]

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.

Re:Writing your own database

[juanfgs]

could perform delicate brain surgery with a Leatherman multi-tool but not so interesting to figure out if you can perform the same surgery with a hand grenade and some duct tape.

BRB, buying duct tape

Preaching to the choir

[Anonymous Coward]

Hey, everyone here still reads Slashdot!

Re:Preaching to the choir

[binarybum]

gold.

Web is a mess

[Anonymous Coward]

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.

Re:Web is a mess

[Shados]

I had that discussion recently at work.

The problem with the JavaScript scene, is that there's basically 2 communities.

One community is actually doing javascript, and trying to find the best ways to go at it, improving on what has worked, using the strength of the language and building on top of it, etc. This is where things like Express, Kao, Babel, Lodash, Bluebird, Mocha, Browserify/WebPack/SystemJS, Aurelia, etc come from.

Then there's the other group, who hates JavaScript, and is basically going: "Hey, pattern/framework XYZ has no equivalent in javascript yet!?! OMG! Why didn't anyone ever think of this????" and go and reimplement it. This is where AtScript/TypeScript/CoffeeScript, Ember, Angular 2.0 (specifically), all the bullshit classical OO stuff, and the 6 million libraries/hour come from.

After a while, you get pretty good at automatically discarding the second group, and as long as you pick stuff from the first, things go relatively smoothly (at least as smoothly as they go in other languages...which means it still has some pain points)

Re:Web is a mess

[Anonymous Coward]

I will happily go with tried and tested, if only web developers would stop reinventing things every six months.

I don't think the problem is javascript. It's HTTP's lack of server-push. Most ugliness is caused by trying to work around that. Wait for HTTP/2 to be more widely adopted, and things will start to change.

Re:Web is a mess

[Anonymous Coward]

The reason the second category exists is because Javascript sucks donkey balls.

If it didn't suck donkey balls, nobody would bother with trying to replace it with something that doesn't suck donkey balls, or at least sucks donkey balls less (or should that be fewer donkey balls?).

Basically, Javascript has no strong points and should be scrapped, but now it has too much inertia (which is not a strong point) and we're stuck with it.

I agree .. BUT ....

[shri]

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.

Re:I agree .. BUT ....

[Lodragandraoidh]

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.

/agree/

Except I would add: "may never ship at all."

The key point here is you aren't betting the company on it, but you still should be doing it. Every company should encourage innovation - and even if the company isn't willing to bet any cash on it. Another way is to encourage your developers to spend some time on their own personal FOSS projects. What this gives you is experience - and from a risk vs. reward perspective, success is attained not by how much working (boring) code you produce, but really how many times you try something that fails, and get up again and keep pushing on with new/modified ideas based upon this experience giving your customers real value. Companies without this perseverance will fail, or at best will be mediocre.

On the flip side - if your core business (the part that you are trying to show your customers you are innovative and a leader in) becomes too boring - and by too boring I mean while it may 'work', it may not do what a customer really wants/needs - then you run the risk of losing those customers to someone who will try and be willing to fail.

Just like all oversimplified prescriptions, the article's concept does not take into account the nuances of business goals, risk aversion level, available human factors and skills, and so on.

Re:I agree .. BUT ....

[Anonymous Coward]

You know what? A good majority of those new techs will become the proverbial flash in the pan before everyone comes to their senses a few years down the road, but not before your system, built on last year's buzzword tech, starts emitting code smells due to much shorter than expected shelf life. To make matters worse, your buzzword system will probably still be farting around in 10 years, long after you're gone, and who the hell remembers what the buzzwords were 10 years ago? The next guy to come along is going to say, "Firebase? WTF is that and why didn't they just use SQL like normal people do?"

Re:I agree .. BUT ....

[phantomfive]

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.

All of those things you just listed are the wrong choice. Seriously. Web-app development hasn't settled down yet, it's still in the exploratory phase, so expect any framework you use to be backwards-incompatible if not completely outdated within a few years.

There is still not a really great solution to web front-end development (and the cynical side of me says that HTML/CSS/Javascript are the wrong answers as well).

Re:I agree .. BUT ....

[Antique Geekmeister]

> There is still not a really great solution to web front-end development

I'm afraid it's because "web front-end development" is about the web front end, and not about the actual content. This is precisely what broke the new Fedora installer, and breaks other interfaces that should be a flow chart with flat text. And in reality, most web pages should be flat text with minimal graphics ecause, behind the scenes, most of them are simple flow charts of flat text content with a few relevant options.

HTML can actually do this reasonably well. Javascript has some uses for it, to handle somewhat more sophisticated options like dates. But most of them do not require a sophisticated GUI. We saw the failure of "web front-end development" with the "Slashdot Beta", which remains one of the the clearest failed "upgrades" since Windows Vista..

Re:I agree .. BUT ....

[shri]

I very seriously agree ... but as a small "community" business, we do need an app or two to allow our users to connect with our websites. Simple things like push messaging to send them notifications, lean data delivery (no need to deliver entire html pages for every pageview) etc etc.

So, the choice is - do we choose a single hybrid framework and learn that, or do we develop for IOS / Android / Windows phones natively and learn three things?

In terms of frameworks etc.. .as long as we can communicate to a PHP / MySQL driven back end, which spits out JSON / XML - the front end can be redone over some time. I think...

Re:I agree .. BUT ....

[shri]

I wish I could mod you up. Spot on ...

Re:I agree .. BUT ....

[phantomfive]

Yeah. The main thing to be aware of is that you'll probably have to rewrite the front-end sooner rather than later (in a newer framework or whatever), so write it in a way that it can be replaced easily (small modular parts, etc) if/when needed.

Re:I agree .. BUT ....

[phantomfive]

breaks other interfaces that should be a flow chart with flat text. And in reality, most web pages should be flat text with minimal graphics ecause, behind the scenes, most of them are simple flow charts of flat text content with a few relevant options.

That's an interesting idea.

Re:I agree .. BUT ....

[dinfinity]

The answer is simple and consists of two questions:
1. How stable is the entity behind what you are going to learn? (Protip: Google and Apple are going to be around for a bit longer than most loosely associated groups of hipster developers)
2. Which of the choices has the most answered questions online (yes, probably on stackoverflow)?

(1) can alternatively be written as 'how stable is the framework/language you are learning?'
(2) can also be seen as 'Which of the choices has the most supportive and/or largest community?'
They boil down to the same, though.

My advice: do it native. Android and iOS devving is really quite easy if you don't want to do anything fancy and do it properly. If you do want to do anything fancy, you're going to have to go pretty deep anyway and hybrid frameworks are just going to get in your way.

I (single handedly) spent about 5-6 months creating a PHP backend and a native Android app, whilst the specs were changing. I had to design and implement the structure of the app and that of the backend, etc. I've started working on the iOS version 1 month ago and it is about done (maybe two more weeks). Mind you: this is not because iOS development is easier than Android development (they both have their quirks), but already having a stable backend and a proven structure of the app code allows me to basically translate the Android code to Objective C without much thinking. The core issues in the system design have already been dealt with. It's just implementing a stable design based on stable specs, which we all know is the easiest part of software development.

Re:I agree .. BUT ....

[gbjbaanb]

lol.The guy I sit opposite has to support a solution built around Biztalk. He continually says "it must have seemed a good idea at the time".

Unfortunately, he has to maintain it, the original weenies who wrote it have moved on to devastate other projects with some other cutting-edge, 'cool' new technology.

Re:I agree .. BUT ....

[Anonymous Coward]

The thing is most of the things in that list of meaningless terms will never be mentioned again in six months time. Most are probably either rehashes of something known since the 1970s or 'hot' technologies that fade into obscurity when it turns out they were not scaleable, buggy or poorly documented.

Boring lasts

[tsa]

It's like Rincewind said: "I like boring. It lasts."

Re:Boring lasts

[Anonymous Coward]

oh ... a book reference! I got it

Sense and sanity

[plopez]

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.

I concur!

[Rogue Haggis Landing]

As someone who has a lot of Perl on his resume, I heartily endorse companies hiring people who work with boring old technologies!

Re:I concur!

[sg_oneill]

As someone who has a lot of Perl on his resume, I heartily endorse companies hiring people who work with boring old technologies!

As a python coder I'm somewhat pleased that my boring old technology is currently seen as flashy new technology right now.

Grunge, is back in fashion, apparently.

Re:I concur!

[Lodragandraoidh]

I would never describe Perl as boring. Annoyingly random, and obtuse, but never boring.

Re:I concur!

[Anonymous Coward]

Like AIDS, it's always changing and impossible to immunize against.

Re:I concur!

[Marginal Coward]

Speaking of annoyingly random and obtuse, didn't James Joyce use Perl as the typesetting language for "Ulysses?"

Re:I concur!

[Anonymous Coward]

I hope not, because that would mean James Joyce is now a zombie which refuses to write.

Re:I concur!

[corporate zombie]

This again. Every language is poor if used poorly. Every technology is poor if used poorly. And the opposite is also true. The trick to getting good technology if used correctly is that some technologies require more discipline on the part of the developer/implementer to use well.

In my company we aggressively mentor everyone so the language (Scala) doesn't have a lot of dark corners. We also mentor the mathematics (I see monoids. They're everywhere!) so that when someone comes across a bit of advanced code almost indistinguishable from magic they don't think "it's magic. I can't touch it." It takes an extra dozen weeks or so but the return is huge (like taking a couple of thousand lines of code and turning it into 80, all nicely immutable to kill those nasty action-at-a-distance bugs).

There's nothing wrong with Perl that isn't also wrong with every other language. They are a tool. If you choose not to learn how to use a tool appropriately don't make the mistake of thinking the tools you know how to use well are intrinsically better.

I would never describe Perl as boring. Annoyingly random, and obtuse, but never boring.

Re:I concur!

[steelfood]

As someone who has a lot of Perl on his resume

So it's filled with dollar signs and completely unreadable?

Re:I concur!

[Anonymous Coward]

I get a lot of flak at work for writing the majority of my projects in DOS BATCH, but I have always been a fan of doing what works. And this makes the programs our employees use easy to understand and improve.

More...

[Anonymous Coward]

Don't repeaty yourself (DRY). Don't re-invent the wheel. Well known for a long time. This isn't news.

Re:More...

[narcc]

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.

Re:More...

[Puff_Of_Hot_Air]

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.

Re:More...

[Shadow of Eternity]

Case in point: Look at the religious hatred for "goto" that has no real technical basis anymore in modern languages.

Re:More...

[Anonymous Coward]

I believe 'goto' has been replaced by the 'if' statement. I believe that 'if' statements should be used very carefully.

I am not talking about 'if' statements for checking return code. I am talking about 'if' statements for decisions.
Every 'if' statements creates a discontinuity in a function, ask a mathematician why discontinues functions are ugly.

Many times you can replace an 'if' statement by using configuration in a different way. Removing an 'if' statement may reduce code size, make it more generic and increases performance.

Re:More...

[narcc]

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.

Re:More...

[fdWv Harry]

but where is the justification for all those impressive job titles in your approach ?

Re:More...

[Anonymous Coward]

Each conditional at least doubles the possible state complexity of your software. Your software should be just complex enough to do what its design says it ought to do and not more complex than that. That said, if you need to branch your logic, branch your logic.

Re:More...

[Anonymous Coward]

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.

Yes, absolutely.

There's nothing wrong with repeating yourself once or twice. DRY isn't about *everything* being non-repeating, it's about avoiding repeating the stuff you do more than a few times. Don't take time to refactor it if you only have two instances of a particular thing. Or even three. It's when you have more than that, that's when you need to refactor.

Re: More...

[Anonymous Coward]

I love the DRY concept. Instead of developing modules again and again, I cut and paste my meticulously developed objects across the whole project and increase my productivity tremendously. Since i adopted this, the average number of lines i developed jumped from an average of 250 lines a week to 50000 lines at time! Now my team mates held me in awe and I passed them those gems so that they can include them in their work too. They are often lost for words on how productive they can be. Sure they complained about codes claiming that I got thing wrong but I could live with jealous inferior colleagues. My unappreciative manages keep nagging me about failing to meet timeline. He is sure misguided. A good piece of software is like an art. It takes time to develop. I sure you all can see the problems with 10 lines database read codes. What about the exceptions? And 5 lines comparator codes? I implement the try and tested selection sort. I know I am a genius but I will still like to thank Microsoft for the cut and paste functionalities.

PS: I do hope that my coworkers are reading this.

Re:More...

[jellomizer]

However the wheel can still be improved. I sure wouldn't want solid wooden wheels on my bike.

Re:More...

[LordWabbit2]

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.

Re:More...

[silentcoder]

>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.

Re:More...

[Buchenskjoll]

Don't repeaty yourself (DRY).

Didn't you just say that?

Re:More...

[TheRaven64]

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.

Re:More...

[qpqp]

Except of course that it IS mathematics.

And the obligatory: xkcd

Re:More...

[Anonymous Coward]

to get to outlook THAT way would take centuries even on the fastest computers we have

That is the understatement of the century. Even counting through all possible "programs" which fit into 16 bytes is impossible in the lifetime of the universe, because there are 2^128 of them.

Re:More...

[silentcoder]

But you don't have to count through all of them. Only until you get to outlook, which is a very long way from the end of the list.

Now if you want to get EVERY useful program from that set which could exist - then you'll have to test every number in the list, and that would take forever even for this reduced subset.
But for just finding one of them - you only have to count until you find that ONE.

Even so the moment you put that upper bound on it you make it possible to use faster algorythms than counting to do the finding with - you could optimize it by using a better data type than a list for example, and using fuzzy logic to search the numbers for patterns you would expect to find in something that's useful (like the string representation of the word "email") to narrow down the search space further.

It would still not be nearly as efficient as doing it the programming way - but that's not the point, the point is merely that it's theoretically possible to do - as proof that programming is still fundamentally mathematics. Just very, very efficient mathematics that make use of quite a bit of intuition that's hard to replicate in generator algorythms.

Re:More...

[TuringTest]

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.

Re:More...

[parkinglot777]

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.

Re:More...

[Archtech]

"...to get to outlook THAT way would take centuries even on the fastest computers we have".

Which would still be FAR FAR TOO SOON.

Re:More...

[parkinglot777]

You, AC, should not pick and choose only a portion of what GP said. The GP point is the "misinterpretation" of the DRY meaning.

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.

.

Re:More...

[Anonymous Coward]

theoretically possible to do

No.

Look, I see your point, but you're really not helping it with your haphazard approach to computability.

Re:More...

[Anonymous Coward]

Um ... not really. Yes, a compiled program can be thought of as a bunch of numbers (a bunch of numbers, not one big number), but that is missing the essential nature of the program. The "numbers" have a significance beyond simply being thought of as numbers. A particular 'number' (or more precisely, a collection of bits) that is feed to the execution of a CPU as an opcode has a significance beyond simply being a number - a significance that the same 'number' lacks if it is operated on as data instead of an opcode.

Software development is the science and art of transformation. We create logic which accepts a collection of inputs and generates a collection of outputs, often using a finite state machine to perform the transformation (meaning the transformation process can be stateful and depends on prior inputs).

The thrust of the original comment is that being "bleeding edge" in one's choice of tools is often neither required nor desirable. This is the piece that many engineers do not understand. There is this thing called "reliability" and another thing called "maintainability" which are very, very important. I had friend who was an amateur pilot. He commented that the engine designs used in small aircraft were 30 years old in many cases and that newer more "efficient" designs were often not used. The reason was simple - the old engine designs were extremely well understood. People knew exactly how they would behave under a wide variety of conditions. People knew how they could fail, how to identify the cause of a failure and how to resolve those failures. That made the older, less "efficient" designs, far more desirable than the newer, "efficient" but less well understood designs.

Most developers think that their job is just to bang out some code then toss it over the wall and call it done. This leads to a lot of short-sited decisions driven by a perception of "coding efficiency" that is driven primarily by "how quickly can I toss this over the wall". One piece of maturity that I try to impart to the developers that I train is that the developer's job is not done until (1) the feature has been incorporated into a shipping product, (2) the product has passed QA, (3) the feature is being used by a customer and (4) another developer has been trained on how to maintain the code. When one uses these criteria for being "done" it forces a very different set of tradeoffs during the development cycle that generally favors straightforward coding using well established technologies.

Re:More...

[ckatko]

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.

Re:More...

[Anonymous Coward]

In theory it is easy to enumerate all programs which are, for example, 128 bytes in size. You just count in binary: 0[1020 zeros]001, 0[1020 zeros]010, 0[1020 zeros]011, ... until 1[1020 ones]111. In that list is every valid 128 byte long program for any processor architecture past, present and future. Obviously you can represent each of these programs by a number, for example the position in the list, which by construction happens to be the number you get when you interpret the 1024 bits as one big binary number.

For some (many) problems in theoretical computer science, this is the way to look at programs. Why theoretical computer science? Because in practice you couldn't even enumerate all possible values of just 16 bytes. There are just too many of them. Theoretical computer scientists are not phased by these problems. They sometimes even deal with infinite machines.

Re:More...

[Penguinisto]

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.

Re:More...

[skids]

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.

Re:More...

[Shortguy881]

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.

Re:More...

[Anonymous Coward]

> Except of course that it IS mathematics.

That is a mischaracterization. As we read on, it's obvious you're contributing nothing to the discussion.

> From the point of view of a computer every program is just one big number.

You are not a computer and past the most trivial problems, no computer program is solely a calculation.
The program is for other developers. After that it's for the computer. This is embodied in the practice of psuedocode.

> 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.

You can also break a sufficiently strong cryptographic hash if you have enough time and energy.
As you assert, that's completely irrelevant because it's impractical so I'm not sure what you're trying to say.

Modded -1 troll

Re:More...

[david_thornley]

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?

Re:More...

[narcc]

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.

Re:More...

[narcc]

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.

Re:More...

[travisco_nabisco]

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)

Re:More...

[ewibble]

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.

Re:More...

[Shortguy881]

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.

Re:More...

[narcc]

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.

Re:More...

[Shortguy881]

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.

Re:More...

[Tablizer]

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.

Re:More...

[Anonymous Coward]

Do you have examples or a real technical basis for favoring "goto" nowadays?

My favorite form of goto is either "throw" or "return". I also like "break", and have occasionally given myself the guilty thrill of a "continue" or two.

Re:More...

[narcc]

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"?

Re:More...

[Shadow of Eternity]

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.

Re:More...

[david_thornley]

State machines have long been considered good uses for "goto". Commenting its use is good, as well as commenting all non-standard code.

Re:More...

[RabidReindeer]

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.

Re:More...

[Shortguy881]

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.

Re:More...

[narcc]

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"?

Re:More...

[Shortguy881]

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"?

Re:More...

[cwsumner]

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...

Re:More...

[narcc]

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.

Re:More...

[gzuckier]

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.

Re:More...

[Anonymous Coward]

of course, when your code was ported over from VBA for MSAccess years ago, and both the author and the porter are long gone, and you don't know if it worked in the first place, and there were never any specs, and you've patched it ten times because they were updates that needed to be done today or else, then every change in something requires you to peruse every line.

Re:More...

[Shortguy881]

No the original argument was as follows:

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.

Re:More...

[narcc]

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.

Re:More...

[Shortguy881]

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.

Re:More...

[narcc]

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!

Re:More...

[Anonymous Coward]

So you add a comment in there noting that that needs to be done...

Debian

[Trogre]

There's a reason I choose Debian Stable for my servers.

Re:Debian

[Anonymous Coward]

So what are you switching too when systemD is the default init?

Re:Debian

[Qzukk]

Debian Oldstable.

Re:Phew

[Anonymous Coward]

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.

Do it for the ops people

[myowntrueself]

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).

Re:Do it for the ops people

[Anonymous Coward]

Yes. I know this for a fact. I'm going through this right now.

Oh, this new NoSQL database is SO fast and wonderful. Except you can't get it to replicate without an Enterprise version, the price of which no one actually calculated into the cost per user budget. Because it's free and open source, except when it's not.

And you need to have at least three servers to run it even without replication. And no, I am not talking about sharding. I mean running a standard one instance of this garbage requires three instances.

Mind you, if you want NoSQL, there are versions out there that have replica sets for free and somehow manage to complete all standard operations with only one server. But we can't use those. No. They're too boring and predictable and STABLE. Not exciting at all.

Not blaming the current developers, who are left with the pile of shit that the other developers made while having all sorts of fun trying shit out and making everyone else figure out how to actually make it *work*.

The last job, they were circling the toilet bowl because we couldn't finish features. Yet their brilliant idea was to switch their technology, and even change from svn to git, and also chef to ansible. This for no discernible reason, other than the fact that it just seemed like a good idea to them at the time.

Bear in mind, I understand why you might want git or ansible or whatever new libraries, but I'd think that we could wait to redesign our whole build process and switch to a new version control system until after we had enough finished features to attract a customer. Or something.

A lot of good people lost their jobs because some architects and a certain CTO wanted to wank off about how bleeding edge they were. Of course, that dumbass still has a job. I hear they're considering a mobile app now. Or something. Good luck with making an app when you laid off all the testers.

With all that talk, you'd think I had gotten laid off. Luckily I managed to get the hell out, but all the people I worked with there got canned a few weeks later. And none of them were fuck-ups. That is the price of not understanding how to maintain a solid foundation to build a project on.

So yeah. Boring. Functional. Boring tech behind your app or site doesn't make it a bad. Bad design does that. Lack of features does that. Failure to understand operating an application on something more complex than your MacBook does that.

The fact that you using the latest thing does NOT make your app good without you knowing what the fuck you are doing.

Best Language for Programming

[Anonymous Coward]

Yippppeeeeee!!!!!!!!!!!!

Infrastructure is boring...

[anmre]

Infrastructure is "boring", but somebody's gotta build and maintain those old roads. Go Civil Engineering!

Re:Infrastructure is boring...

[Anonymous Coward]

Infrastructure is "boring", but somebody's gotta build and maintain those old roads. Go Civil Engineering!

Or you could simply stop maintaining infrastructure like we did in the US.

Re:Infrastructure is boring...

[Anonymous Coward]

The why my civil engineer friend now works as a software consultant.

We all need to telecommute now that it's unsafe to cross a bridge!

Re:Infrastructure is boring...

[Anonymous Coward]

Just as planned.

i still use LAMP

[Anonymous Coward]

Works great for me. Stay away haters.

If you're bored, you're boring

[Zero__Kelvin]

II can't imagine what could go through someone's mind that they would even consider that 'boring' vs. 'not-boring' is even something to look at when deciding which technology to use, with the sole exception that all other things being equal clearly the more exciting one will pay bigger dividends due to increased developer interest.

What constitutes a boring technology? Say I agree with you that COBOL is boring; will Johhny down the road agree with us, or will it fascinate him? Now, let's say that we all universally agree that COBOL is some boring ass technology (unless you rode the short bus to school, I think we can :-). Should I really design my new project around it?

OK. Now on to the actual reading of the article:

"Let's say every company gets about three innovation tokens"

OH ... how about let's not and say we didn't. So basically, the author claims to be a skilled software developer, but can't figure out that subjective criteria isn't your best bet when analysing data sets, and who can't figure out that you need a premise that isn't absurd to churn out a non-absurd result.

"What counts as boring? That's a little tricky."

Yes, well that explains why you never actually even attempt to address the question so fundamental to the understanding of your entire theory then, I suppose, isn't it?

"Taking this reasoning to its reductio ad absurdum would mean picking Java, and then trying to implement a website without using anything else at all. And that would be crazy. You need some means to add things to your toolbox."

Can't you use old 'boring' technology in this case? Don't use Mongodb; use Mariadb/MySQL. Old; tried and true; as 'boring' as it gets by this guy's implied but never stated definition.

... and I just went back and read the subtitle under "Dan McKinley", to wit: Math, Programming, and Minority Reports." Sir, if you are reading this, I have no doubt you are far better a Mathematician than I, but you seem to have made the mistake of thinking that being good at Math and being able to write a few scripts has placed you in a position to pontificate poignantly on subject matter with which you have no actual grasp. Please leave the Software Engineering to the Software Engineers, and I promise not to try to write papers in Math journals. Thanks!

Re:If you're bored, you're boring

[Antique Geekmeister]

> 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.

Re:If you're bored, you're boring

[Zero__Kelvin]

"I'm afraid that's the fine print. "All other things being equal". ..."

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.

Re:If you're bored, you're boring

[david_thornley]

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.

Pete Townsend as my guide

[WinstonWolfIT]

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.

The danger of ngXYZ

[mtippett]

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...

There is art in engineering

[Anonymous Coward]

I don't mean Industrial Design.

Steve Wozniak's circuit designs for the Apple I and Apple II computers were pieces of true engineering, but also pieces of art and filled with "clever" bits.

Re:There is art in engineering

[Puff_Of_Hot_Air]

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.

Avoiding smart risks is often far riskier.

[Anonymous Coward]

New technologies can often enable completely new business capabilities and strategies that old technologies just can't. E.g.

- Maybe it's far more flexible, cleanly coherent and understandable, so your business will be faster to adapt & outmaneuver competitors.
- Maybe the new tech just takes far less code, complexity & overall time.
- Maybe it's far easier to test & deploy, so your quality will be better.
- Maybe it supports emerging standards with community backing and your business will be left behind when competitors adopt it and customers demand it.
- Maybe it's an off-the-shelf library, by teams with dedicated expertise, instead of writing your own. Instead of wasting your own budget, you can benefit from the work & future ongoing improvements of a larger community than you can individually afford.
- Maybe the new tech can dramatically cut operating costs & resources through better automation.
- Maybe the new tech will just have a much longer 'shelf-life' (ongoing support & compatibility with it's ecosystem), so you're not forced to rebuild it too early.
- Maybe the much greater engagement & motivation you get from tech staff working on exciting, enjoyable (not-boring) tech will have it's own pay-off. Boredom can induce coma, laziness disengagement and alternative job seeking (or worse if they stay), whereas interest & appropriate challenge can spark creativity, innovation & enthusiasm.
- Maybe you're missing out on opportunities to break new ground and deliver customers better experiences than they're used to.

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.

Always explore your options. Consider whether there are 'both/and' options instead of just 'either/or'. E.g. Is the pay-off potentially so great that you can run both technologies in parallel, while still having better odds of coming out in front? Can you easily test & prove/disprove the new technology in an isolated, low-cost module first? Will the cost of failure be completely catastrophic, or leave new options & learning?

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.

Re:Avoiding smart risks is often far riskier.

[rjstanford]

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.

Re:Avoiding smart risks is often far riskier.

[WaffleMonster]

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.

Different for proprietary and open source

[iamacat]

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.

Let me tell you why that's bullshit.

[Anonymous Coward]

1. If you're a lunatic talking about 'innovation' tokens and are using HTML 4.01 and Flash instead of HTML 5 to deliver a rich media experience, you're a fool.

2. If you're using PHP instead of something like Node for your webapp, merely because PHP is 'old', you're a fool.

3. If you're using MySQL for storage of data that doesn't rely on structured relationships, because MongoDB is somehow "too new", you're a fool.

4. If you're still using CFEngine 2 because fuck those people, you've been using CFEngine 2 forever, you're a sysadmin. And possibly a fool.

Re:Let me tell you why that's bullshit.

[Anonymous Coward]

Now that it has been adequately covered that you're probably an idiot, you can sit down.

The best compliment I ever had

[GerryGilmore]

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....

Stopped reading after..

[kuzb]

"Let's say every company gets about three innovation tokens."

Bullshit hypothetical statements are bullshit.

Training & Help

[Tablizer]

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.

Bad advice maybe?

[countach]

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.

The normal and the revolutionary aspects

[m.shenhav]

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.

Re:The normal and the revolutionary aspects

[ckatko]

Likewise: I know of people so afraid of "being a cowboy" they use all of 10% of a programming language's feature set because they're too afraid to mess something up if they... learned something.

Re:The normal and the revolutionary aspects

[Anonymous Coward]

Indeed, the right answer is to learn all (or at least as much as you can) of a language and know when to use this versus that.

Writing python I always hate seeing things like: if thing not in thislist: thislist.append(thing). I look at that and just think, man why didn't they just use thisset.add(thing). And the answer is, they didn't know about set.

Re:The normal and the revolutionary aspects

[Anonymous Coward]

I got into trouble for using popular features of a language, because my dinosaur supervisor and her dinosaur supervisor weren't experienced with them.

KualiCo are you listening?!

[Anonymous Coward]

ERP done all in javascript using reactjs (before the 2.0 rewrite was announced)? Looking forward to July to see your success.

Re:Phew

[_merlin]

Is Bennet still allowed to post? I haven't seen any of his ramblings for a while.

DB2 has it too

[tomhath]

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.

Don't minimize Wozniak's's cleverness

[Anonymous Coward]

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

Well duh..

[bravecanadian]

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.

Anyone mention Ada yet?

[Archtech]

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.

boring? yep, and reliable...

[Anonymous Coward]

Well, I have seen a LOT of progrmmers put in something just because it is the latest and greatest ( Ohhh! Shiny! ).
XMl where it was not called for, Flash where it works but is slower, a script in some version of JS because that version was the latest on the
review list.... third party libraries that implement something 'neat'...
Then there's Microsoft - who tries to invent the new and shiny... and usually backs out after a couple of computer generations ( 3 years each ).
The increase in the learning curve and the innate compexity lend themselves to sensitive code... just a small change is a disaster that is nearly impossible to fix.

So you want code to last and work for thirty years? Like the old COBOL finance programs? Or the old FORTRAN/ASSEMBLER engineering programs?
KISS! and if anyone has trouble understanding the code because of the code and not their own ignorance, then simplify it even more!

Complete design before coding - use pseudo-code to design, maybe even work through behavior by hand on paper with an ink pen...
Another way is to apply Karnaugh maps to the state logic variables and program behavior, which should be sufficient to make you inderstand the complexity of a system... and maybe reconsider having such a complex piece of work - reduce the complexity, simplify and then program.
KISS! DO YOU PROGRAM, M**F**ker!

Brilliant!

[neurovish]

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.

Re:Brilliant!

[Anonymous Coward]

i assume, KISS, u r being sarcastic ?
KISS = keep it simple stupid,old when i was a lad in the 60s

Support and Resources

[DarthVain]

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...

Re:Support and Resources

[DarthVain]

Also I forgot, because the tech has been around for awhile, they also usually have better integration capabilities, as other technologies may already leverage it, and the connectivity is understood and well documented...

why on earth

[Anonymous Coward]

do we need this post ?
isn't this something that every single comp sci student is taught from day one ?
isn't this something that an engineer, by definition, knows (KISS) ?
why do we have to keep relearning that 2+2 =4 ???

Learning is a margin cost, work is a fixed cost

[Anonymous Coward]

I manage a team of devs and a project I run sparked a large federal agency to nominate us for their small business of the year. We also have had four years of INC5000 growth, which is pretty good for a government consultancy. I disagree with the OP. Tech doesn't cause success whether you use boring stuff or fancy stuff. There is no silver bullet either way. We happen to use a lot of fancy tech, but we made each choice based on an accounting of time savings. Our writing web apps in fancy Django+continuous integration+cloud saves an order of magnitude of time compared to boring java servlets plus typical migration process. We pass the savings on to our customers.

What it comes down to is that the major cost of new tech is learning. If a new technology lowers work, you're reducing a fixed cost (developer work). If the new fixed cost plus the amortized margin cost is lower, a new technology is the appropriate choice. It so happens that when I do that calculation on most new technologies (Node.JS for instance), there is not a large enough savings to justify the risk. For some other technologies (Django), the savings is so huge that we are able to offer profitable rates that are astonishingly lower than competitors. That lower price boils down to the fact that we do a tiny fraction of the work compared to our competitors to produce a superior product.

Saying that the boring choice is the right choice is a fallacy. Technology has for thousands of years driven improvements in productivity. Just because the improvements are smaller today than they were in the 90s or 2000s doesn't mean they aren't worth pursuing.

Everything in moderation

[Anonymous Coward]

A true "rockstar coder" will know when it makes sense to do the obvious thing, and when there are gains to be had by doing something clever to save the day. This is why Star Trek is inspiring for many Tech Leads, they recognize that sometimes you should follow protocol, but when shit hits the fan a good leader can improvise and not let projects fail or staff get laid off through cunning actions and negotiations.

It's why I used hosts vs. malware, ads, spam

[Anonymous Coward]

"BORING" (but proven, efficient, simple & effective) for: APK Hosts File Engine 9.0++ SR-2 32/64-bit:

http://start64.com/index.php?o...

FREE & adds speed, security, + reliability, doing more w/ less, more efficiently vs. addons + fixes DNS' redirect security issues:

---

A.) Hosts do more than:

1.) AdBlock ("souled-out" 2 Google/Crippled by default http://techcrunch.com/2013/07/... & ABP too http://finance.yahoo.com/news/... )
2.) Ghostery (Advertiser owned) - "Fox guards henhouse" http://en.wikipedia.org/wiki/G...

B.) Hosts add reliability vs. downed/redirected dns (& overcome site redirects e.g. /. beta).

C.) Hosts secure vs. malicious domains too -> http://tech.slashdot.org/comme... w/ less "moving parts" complexity

D.) Hosts files yield more:

1.) Speed (adblock & hardcodes fav sites - faster than remote dns)
2.) Security (vs. malicious domains serving malcontent + block spam/phish & trackers)
3.) Reliability (vs. downed, Kaminsky redirected (99% ISP DNS' = unpatched vs. it), DGA, Fastflux, & dynDNS botnets)
4.) Anonymity (vs. dns request logs + dnsbl's).

---

* Hosts do more w/ less (1 file) @ faster levels (ring 0) vs redundant inefficient addons (slowing slower ring 3 browsers) via filtering 4 the IP stack (coded in C, loads w/ os, & 1st net resolver queried w\ 45++ yrs.of optimization).

* Addons = more complex + slow browsers in messagepassing (use a few concurrently & see) & are nullified by native browser methods - It's how Clarityray's destroying Adblock.

* Addons slowup slower usermode browsers layering on more - & bloat RAM consumption + excessive cpu use too (4++gb extra in FireFox https://blog.mozilla.org/nneth...)

(Work w/ a more capable native kernelmode part you already have - hosts (An integrated part of the ip stack))

APK

P.S.=> "The premise is quite simple: Take something designed by nature & reprogram it to make it work for the body rather than against it..." - Dr. Alice Krippen: "I am legend"

...apk

Re:It's why I used hosts vs. malware, ads, spam

[Anonymous Coward]

Speaking of boring, oh look it's another tangled, messy rant from APK. Yawn.

rules of 3s.....

[OutOnARock]

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...

It depends how good/bad the old shit is

[presidenteloco]

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.

Re:It depends how good/bad the old shit is

[phantomfive]

That sounds like a reasonable, balanced approach. We need more guys like you here on Slashdot.

well said

[Phantom of the Opera]

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.

Re:well said

[MisterSquid]

People sometimes forget that their job is to solve problems rather than writing perfect programs.

Such an eloquent a reminder. Thank you.

Mathematics is NOT a science!

[Anonymous Coward]

Mathematics is not a science. Science is empirical, math is rational. Applied math can be empirical. Learn the difference and don't misuse the terms again.

Also, if you're going to talk about whether programming is math, you should probably talk about Turing machines and lambda calculus. E.g. Why is it important that programs are numbers? Answer: it's not, it's just one representation, and computation would still be just as effective if one used other symbols (per Turing). Programming is math because it is composed of mathematical statements, not because it is encoded with numerical instructions.

Really?

[junkgoof]

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.

Re:Really?

[bluefoxlucid]

The main point is not to jump into new things in your industry. When I grabbed for MongoDB, it wasn't MongoDB 0.2 alpha or 1.0 or whatnot; it was MongoDB 2.2, a relatively mature product. At the time, it was new to the industry: a lot of articles on Slashdot and so forth were jabbering about these new "NoSQL" databases and "Document stores" and whatnot, and arguing their merits and shortcomings. The article proscribes that MongoDB would be something that cost me an "Innovation Token" if I were to grab it right then.

My point is that I did just that: I saw MySQL wasn't working, at all, for our projects, and that MongoDB fit some of our needs much better. Our software design and code became orders of magnitude more manageable and efficient. After that, we rewrote the MySQL calls as ORM, while using MongoDB via direct query--we quickly integrated and profited from two new technologies, reducing our risk and streamlining our business.

We did exactly the opposite of what the article says, and gained great benefits in opposition to what the article claims. By identifying and selecting the correct tools, be they old or new, we opened the path to innovation, allowing ourselves to carry out new strategies and develop new ideas quickly and effectively.

Exactly same is true of compilers, processors, etc

[Anonymous Coward]

Exactly same is true of compilers, processors, etc.

(hardware is just frozen software.)

All practical programming, (beyond purely theoretical models or toy projects), involves using components that are not fully known, trusted or verified.

That's just life.

Ok: What've you done better?

[Anonymous Coward]

See subject: Zero (you know it, I know it - all reading do!)

* :)

(I love telling the truth about online scum like you...)

APK

P.S.=> Being a trolling "ne'er-do-well" online such as yourself, your entire life, is NO way to live your life, loser... apk

Oh brother...

[iq145]

How about boring news?