Why You Should Choose Boring Technology 232
An anonymous reader writes Dan McKinley, a long-time Etsy engineer who now works at online payment processor Stripe, argues that the boring technology option is usually your best choice for a new project. He says, "Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble. ... The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."
A Corollary for Code (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Insightful)
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: (Score:2, Informative)
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: (Score:2)
I was clearly in your second group a few years back...
Maybe you just were not sexy enough, hm?
Re: (Score:2)
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?
The normal and the revolutionary aspects (Score:5, Insightful)
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: (Score:3)
Re: (Score:2)
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 (Score:5, Informative)
Re: (Score:2, Informative)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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: (Score:3)
Re: (Score:2)
"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 fa
Re: (Score:2)
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: (Score:3, Interesting)
"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: (Score:2)
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:More... (Score:5, Insightful)
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... (Score:5, Interesting)
Re: (Score:2)
This problem isn't just in pure developer-land.
As an example, meander on down to the PuppetForge [puppetforge.com] 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 [puppetlabs.com], and you'd think they were writing Turing-capable climate modeling software. Okay, I exaggera
Re:There is art in engineering (Score:5, Insightful)
Re: (Score:3)
Case in point: Look at the religious hatred for "goto" that has no real technical basis anymore in modern languages.
Re:More... (Score:4, Informative)
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:3)
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 limit
Re: (Score:3)
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: (Score:2)
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
Re: (Score:2)
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 co
Re: (Score:2)
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... (Score:4, Insightful)
>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: (Score:2)
Except of course that it IS mathematics.
And the obligatory: xkcd [xkcd.com]
Re: (Score:2)
Every time some links to the obligatory xkcd, I remember the numbered jokes [realnothings.com] 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: (Score:3)
"...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: (Score:3)
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 themsel
Re: (Score:3)
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
Re: (Score:2)
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: (Score:3)
However the wheel can still be improved. I sure wouldn't want solid wooden wheels on my bike.
Re: (Score:2)
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 cos
Absolutely (Score:3)
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: (Score:3)
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 (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 imme
Re: (Score:2)
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 inn
No one ever got fired for buying IBM (Score:5, Insightful)
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: (Score:3)
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: (Score:2)
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 (Score:5, Insightful)
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: (Score:3)
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 g
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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...)
Plain old boring rules (Score:5, Interesting)
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.
DB2 has it too (Score:2)
Re: (Score:3)
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: (Score:2)
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.
Web is a mess (Score:5, Insightful)
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: (Score:2)
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, p
I agree .. BUT .... (Score:5, Interesting)
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 .... (Score:4, Informative)
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: (Score:2)
I wish I could mod you up. Spot on ...
Re: (Score:2)
> 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 a
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:3)
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.
Boring lasts (Score:5, Funny)
It's like Rincewind said: "I like boring. It lasts."
Sense and sanity (Score:3)
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! (Score:5, Funny)
Re:I concur! (Score:5, Funny)
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! (Score:5, Insightful)
Re: (Score:2, Funny)
Like AIDS, it's always changing and impossible to immunize against.
Re: (Score:2)
Speaking of annoyingly random and obtuse, didn't James Joyce use Perl as the typesetting language for "Ulysses?"
Debian (Score:2)
There's a reason I choose Debian Stable for my servers.
Re: (Score:2)
Debian Oldstable.
Do it for the ops people (Score:2)
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 (Score:4, Interesting)
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.
Pete Townsend as my guide (Score:2)
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 cod
The danger of ngXYZ (Score:3)
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...
Different for proprietary and open source (Score:2)
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 pr
The best compliment I ever had (Score:3)
Stopped reading after.. (Score:2)
"Let's say every company gets about three innovation tokens."
Bullshit hypothetical statements are bullshit.
Bad advice maybe? (Score:2)
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
Well duh.. (Score:2)
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? (Score:2)
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 sur
Brilliant! (Score:2)
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.
Support and Resources (Score:2)
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 y
Re: (Score:2)
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...
Re: (Score:2)
gold.
Re: (Score:3)
> 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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Is Bennet still allowed to post? I haven't seen any of his ramblings for a while.
Re: (Score:2)
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 cos