Learning (needlessly) hard technology

A few years ago, a friend told me he was thinking about learning a certain technology because it was really hard to use. This was not something that had to be complex to solve a complex problem, but something that was unnecessarily complex. Why would anyone do that?

His reasoning was that as a consultant, he could make good money supporting a technology that’s hard to use. My friend would have more integrity than to recommend something that he didn’t think was a good solution. Perhaps he was thinking of saying something like this to a client: “I wouldn’t recommend this technology if you were starting from scratch. But since you’re invested in it, I’ll help you with it or help you migrate to something else.”

That sounds like an unpleasant way to earn a living. It also sounds risky. If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. (This assumes people are free to choose alternatives, not prohibited by law, for example.)

Learning a technology that’s complex for good reasons could be a smart and ethical move. The work is harder at lower levels of abstraction, but someone has to solve the problems others would rather not think about. And since not as many people can do that work, it should pay better and be more secure.

There are a couple dangers, however, associated with choosing a more difficult technology. One is the temptation to use it where it isn’t needed. The other is that the set of problems where it is needed may shrink over time.

More programming posts

9 thoughts on “Learning (needlessly) hard technology

  1. Software is politics. Pork barrel politics. If you can get a mark to buy into a needlessly complex technology or solution, then you are issuing yourself a license to print money. Its’ called Enterprise Software Development. :-)

  2. This is very common, though more often expressed with other words: “we specialize in the technologies that our customers use” and “we’re the best, no one has so much expertise in this tech.”

    That way sounds a lot better than “whatever they pay more” and “because who else would could or want to touch this shit.”

  3. It is a risky proposition plus the market forces will address needless complex software. The only models that will thrive are information analysis (exhaust). Software and hardware will eventually go free or near free. You have to generate the info / data on behavior cheap. Complexity will be seen as a cost and reduced to increase data collection and analysis. Customers want to know how to make their products better and who ever can do that at the best rates wins.

  4. So what? Better alternatives arise? Sure.

    However, most businesses have invested in hard technology X and won’t switch anytime soon, since the cost and risk of switching far outweights working with easy technology Y.

    A lot of businesses work that way.

  5. “the cost and risk of switching far outweights working with easy technology Y”

    That depends on how many pies it has its fingers in.

    Apache was too complicated, and everybody knew it. When nginx arrived on the scene, it was pretty easy for everybody to swap it out, because HTTP servers don’t really do that much. GCC was (way!) too complicated, and then Clang came along and ate its lunch. There are lots of examples of complex programs replaced in very short term (even at big enterprise companies) because the newer version is just like the old one but simpler and better in all respects.

    If it’s something like a programming language, that’s obviously going to be a lot harder. Perl was too complex, but it hung around for a long time because you can’t replace all your Perl code overnight (like you can with an Apache config file).

    Even so, I’ve worked at Big Companies (Fortune-50) that take years to approve anything, and they do sometimes get simpler solutions approved in remarkably short time. Once my former company discovered that all their engineers were using Python, they were quick to put it on the official list, lest they face a software mutiny.

  6. REST beat out SOAP. That made me happy.

    Nothing has replaced CSS yet. I suppose it’s hear to stay because it’s too hard to replace at this point.

  7. I learn things that are hard (for me) because there’s almost always something generally applicable to my work as a technologist.

    I recently started working with Hadoop, having come from Lucene/Solr/ElasticSearch, and some other technologies around data. Hadoop intersects with these technologies in many useful ways. I now can advise my company on how we might use search to solve some problems, and have learned new ways to accomplish some problems we had in my last place. And in both cases I see brilliant designs as well as errors in the architectures of the products, as well as just interesting decisions, even in simple things.

    No one at my company knows AWS. Because I learned it years ago after moving from managing our own hardware I know how to make it work in ways that seem normal to me, but had been frustrating to people used to working with hardware. I know both so can understand the differences and explain trade offs using non-inflamatory language. It is not the case that AWS sucks. It is not the case that managing data centers sucks.

    When I first started consulting, I happened to have rare knowledge and used that to get paid better. But the technology I knew was rare for a reason, and managed to help my customers get away from the old to something new.

    So many reasons to learn hard new things. Only reason not to is that it hurts.

Comments are closed.