Hacker News Reader

Comment by binwiederhier | Hacker News Reader

> You can rewrite it from scratch, using a different language or technology. This way, you learn something new rather than patching legacy code. And if your architecture doesn’t allow this yet, you can take steps to improve it, and learn some devops skills in the process.

In a professional environment, we develop software not because it's fun, but because it supports the business and/or because it is the business. The primary purpose is to make money and to pay our salary. Now, that doesn't mean that coding can't be exciting or that you're not supposed to have fun. Not at all. But I feel that the author largely fails to see the business perspective. Rewriting things from scratch, adding another language to the overall architecture, using some fancy new technology, etc. are not wise business decisions in /most/ cases. Especially the comment about "using a different language or technology" will lead to a maintenance nightmare in the future ...

View on HN

Most engineers take years to internalize this concept. Fresh out of school programmers will throw themselves at tough problems, get 80% of it done using the latest popular framework before they want to move on. The problem is, the remaining 20% is often what will drive success or failure.

As a CTO/manager/team lead, your objective is to mitigate things; keep things interesting enough while getting things done.

This usually means avoiding over-engineering, leaving some room for the team to pick the tools/technology they want (as long as they understand they will assume its maintenance) and making progress visible (celebrating milestones, having regular stand-ups...).

And even then, people will leave (some programmers can't get the remaining 20% done), shitty code will creep in and have to be maintained, and you will occasionally have to deal with legacy stacks. And that's fine.

If you call it quits because you don't want to get your hands dirty, I'm not sure I want you on my team.

I spun my wheels for the first half of my stint at a tech company by being the sort of full-stack developer who never really specialized in anything. During that time, I frequently noted that the engineers who were promoted to the top were specialists in one or more areas important to that company's goals. My managers always told me I was mistaken about that.

So eventually I specialized in one of those areas and got promoted myself during the 2nd half, so much so that Google poached me (that didn't end well, but that's another story). These days, I work amongst the full-stack crowd who want everything written in Python so they can modify supposedly low-level inner loops with impunity. When repeatedly confronted with a C or GPU procedure that is 50-100x faster than its Python equivalent (dynamic typing in inner loops is a harsh mistress and even numpy can make Python coders do really strange things leaving one with code still 5-10x slower than bespoke C/GPU code), they complain about the difficulty of writing C/GPU code rather than consider the performance they're leaving on the table and the money they're wasting by running performance-sensitive code that way.

But then, I've always considered getting my hands dirty and rooting out bizarro bugs the fun part. The hardest part for me is when to say a project is done because I can always find room for improvement. And I prefer to work with people who have a similar viewpoint. It's not easy to find them.

The project is done when we add the "it works" feature ;)

"Python for impunity"

I was wondering why I keep seeing this everyone. Python this, Python that.

Its very much the case that new engineers want to work on the hardest projects and prove that they are capable and deserve lots of money and/or responsibility. But management typically doesn't care if you completed 99% of the hardest project on the block if it doesn't yield a usable result (nor should they). Its generally better to solve a simpler problem well enough to at least claim success. The downside is that if everyone feels that way, the quality of the framework for future tasks is not robust and technical debt racks up. Without a sound framework, there isn't reliable infrastructure and navigating previously written tools can't be trusted by glancing at a method or package name. It turns a depth 1 BFS into an unbounded DFS and eventually it becomes extremely time consuming to get anything done. The problem gets compounded if there is a lengthy review process and the reviewer is safer doing nothing, letting the change languish until a manager pushes for it.

Here's how I would interpret things. Each method ("old & boring", "new & interesting") has costs and benefit for the company, and cost and benefits for the developer. The naive way to make a decision on which tech to use is to do a CBA for just the company, but this essentially incurs hidden costs for the developers (boredom) which eventually is inflicted on the company (quitting). So make your best effort to estimate those hidden costs and factor them into your decisions.

That doesn't mean always choosing new & interesting, it just means that when the business CBA gives only a slight preference for old & boring, you instead err on the side of new & interesting. This is just advice "on the margins". When the boring tech is clearly much better than the interesting tech, you still stick with the former.

I am bemused simply by the author's idea that rewrites are interesting. It is probably a good sign if a developer is irritated by cruft in existing code, but to feel compelled to redo the whole thing 'properly' strikes me as borderline OCD (full disclosure: it happens to me occasionally, but I quickly get over it.)

> it happens to me occasionally, but I quickly get over it

By realizing that you'll make even bigger of a mess the next time around?

AKA The Second System Effect. :)

https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sec...

That is probably the rational assumption for me to make, but I'm not that much more self-effacing than the average programmer. What usually does the job is contemplating the amount of work it would take to divine the current implementation's requirements[1] and the amount of testing that it would take to show that I had correctly implemented them. That is when I realize I can live with the existing implementation and that I have other things I would rather be doing.

[1] If it were self-documenting, or even just documented, I would probably not be thinking of fixing it.

http://www.joelonsoftware.com/articles/fog0000000069.html

I usually find it's a sign of a developer who's too lazy to understand the current code, but arrogant enough to think they can make it better by starting again.

Yip, you can't really do a re-write unless you've gone to the bother of understanding what is there in the first place (and wrapping tests around it, if at all possible).

And if you're going to the trouble to understand it and wrap tests around it, then maybe refactoring the existing codebase is a smarter choice. If less sexy.

I think a good mindset to have is to look for the challenge in making decent refactorings.

It's a wise decision if you care about engineers being engaged and liking their job.

I've seen these types of projects where a few developers just went overboard with all the new frameworks and languages. Two years or so later most of them have moved on and other devs are stuck with technologies that are now considered outdated. Especially in the JS world, that's a real scenario.

I am all for keeping your engineers happy. Heck I am one of them. "Exciting" can mean "better architecture" or "extensible", but I think that adding a new language is always a bad idea.

> other devs are stuck with technologies that are now considered outdated

Isn't that a case of not letting developers rewrite anything? How did it got so outdated?

Anyway, the Javascript world sucks. Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.

> Isn't that a case of not letting developers rewrite anything? How did it got so outdated?

If you're writing (or rewriting) using whatever's hip/new there's a good chance it will be "outdated" within a few years. New languages and frameworks come out all the time and nobody is able to determine with certainty which have real staying power - but something that has been in [wide] use for 10+ years is much more likely to still be widely used ten years from now than something that just came out last year.

Think of it like music, people have been listening to Mozart for centuries - it's highly likely a hundred years from now people will still enjoy his music. It's a lot less likely they'll be listening to Taylor Swift (nothing against her / her music - just using her as an example of someone who's very popular right now).

There's also a chance writing your project on that 10+ years old platform will cost you enough time/money to write it three times in a more modern one.

Well, you sound like somebody who I'd agree with most actual decisions about this. But I do disagree with the overall position. Holding down too much at "it works, don't change" has actually worse consequences than adopting immature frameworks all the time. That's not exactly like music - software tools do get old.

Good platforms, of whatever age normally last for a long time and should be safe. But if for some chance one didn't last, one shouldn't be too resistant to replacing it (piecewise and slowly), because the cost of not doing that is just too big.

> Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.

I don't think it's that they get outdated. It's that they each try to solve the hardest problem of web UI programming: keeping track of state and binding data in an asynchronous world. Unfortunately, each one ends up with pain points in different places.

Each successive framework tries to solve the new pain points by rethinking the original problem, because reworking the original framework to ease that pain point would often require massive restructuring of apps built on that original framework - the issues are often architectural.

Angular, for example, is fantastic for getting a very simple CRUD app up and working. But try to do anything fancier and things get very hairy very quickly with a web of controllers, directives, scopes, etc. Getting into a place where one data change cascades and kills your app is a very real concern. That's the pain point React/Flux attempts to solve. Angular can't solve it without some major architectural changes - see the hubbub about Angular2.

We're still in the baby stage, I feel - while each successive framework may seem faddish, they don't really get outdated. Out of favor for new projects, perhaps, because the developers who used the older framework were so frustrated with the previous tool's rough edges. Things will probably settle down soon (especially with the fantastic language improvements in ES2015) :)

You know, if Microsoft developed all its other applications in VBA and ran them inside Word, they'd be a laughing stock.

But everyone else in the world thinks it's sane to write applications inside a thing meant for displaying documents...

Got a better solution, with wide adoption, that can get you on just about every internet-enabled consumer-facing computer in the world with the same codebase? :)

Indeed, and it is not just with frameworks and languages, but also architectural and methodology fads. Several times, I have seen those who see themselves as architects try to roll their own frameworks or even languages within a project (the 'inner platform' phenomenon, which is quite common.) Those I have seen have all been failures, once catastrophically so.

As a result of its effects on the work of other members of the team, such people often have a negative net productivity. I, too, am in favor of making things interesting where possible, but not to the point of indulging the Dunning-Kruger effect.

Ha. I mean, every engineer loves a green field project, and everyone wants to do a technically sweet project. But engineers of all people should understand that not every project can be technically sweet, and certainly not every project can be greenfield.

Could you imagine if everytime you wanted your HVAC upgraded, your contractor decides to rip out your entire current system and replace it with something new ("this new polymer ducting is awesome!") just to keep their engineers happy?

There's a time and a place for all types of projects, and the mark of a successful engineering effort is to have engaged engineers regardless of the 'cool factor' of their work.

In fact, this whole thing stinks of poor leadership (not just management) and undisciplined engineers.

Engineers always under estimate the amount of business logic in an existing application. This is one reason my mainframe apps are so hard to replace, they often have 30 years of business logic built into them.

I agree with you on principle, but I've always wanted to see one of these "30 years of business logic" apps up close. What's most of that business logic? I can't imagine all of it being essential and at the minimum possible complexity.

"Normally, component A completes then sends a message to B, who blocks while a file operation occurs, and then sends a confirmation to C which updates the UI. When configuration option D is enabled, B must make the write twice because of X, which requires component E to act as a delegate to intercept the normal message from B to C so that this can occur without changing the implementation of C, since it has been externalised and is used in six other projects. Also, file writes are disabled on weekends, except the fourth weekend in February, unless this weekend doesn't occur."

-- snippet from a more or less realistic set of requirements for a "2 years of business logic" app. I do not want to be here in another 28 years...

In the backend, a new language for a new service would likely be ok, if it's pretty small.

If you chose any of the major frameworks for your application you'll be good. Django, Rails, Java EE, Spring, Play Framework, Meteor. These aren't likely to go away anytime soon, and they've been around for a while.

On the front end it's a much more dangerous approach. If you have one or two pages that use the latest flavor of the month, Backbone(2011) Knockout(2012), Angular(2013), React(2015), you'll be ok.

The problem comes when you just re write your entire front end app in one of these. I like to experiment with front end technologies on one page, but I would never buy into the SPA for the entire app. The shelf life is way to small. They'll still be supported probably.

If your trying to keep or hire developers, putting backbone.js as a tech you use probably won't get as many applicants as say React.js. Since most front end devs right now are trying to introduce React into current job or jump to a job where they use it.

I've personally seen this cost a company millions of dollars and years without a next product.

If an engineer gets bored and leaves because they wanted to rewrite your codebase and you said no, that's probably not an engineer you wanted to retain anyway.

Even if you said yes, you're only kicking the problem down the field a bit, because six months later they'll get just get bored of the new stuff they've rewritten and will want to move on to rewriting something else. Ad infinitum.

I consider these people the "90% engineers", meaning they like to take a project from 0% to 90% complete, but then once the going gets tough, and they're no longer writing new code but trying to track down the bugs in their existing code, they decide it's no longer fun and need to move on to something else.

These people usually fail to realize the implicit risks associated with throwing away an existing codebase and starting over from scratch. All that time spent ensuring the business logic is correct and tracking down obscure bugs will need to be repeated in their new rewrite. (Spolsky elaborates: http://www.joelonsoftware.com/articles/fog0000000069.html)

These people are essentially spinning their (or rather, their company's) wheels by creating more work for themselves, without actually getting anything done.

The business perspective shouldn't overlook the direct and indirect costs of engineer turnover.

Aren't these vagabond workers destined to leave anyway?

They seem to me that they have this wanderlust to switch jobs and try something new every couple year and get a kick out of it. I don't think that there's much to do to retain them and make them feel excited all the time.

They can often be the ones who love their craft, enjoying evaluating new approaches, spend their own time coding and learning the latest frameworks, and can be the best coders on the team, able to tackle the more difficult problems with the best solutions.

But also refuse to maintain either the software they wrote or the older version that is still bringing in money while the new version is being written.

Chuck 'em. Nobody needs that type of developer.

> Aren't these vagabond workers destined to leave anyway?

Even if not, they may not be paying attention to things that matter to your business, and may ultimately do more harm by staying.

I'm sure there are some who just like changing jobs. But most of the programmers I've known have moved when they could get more money or thought they'd have more fun at the new job. If you're paying well and keeping the fun factor above average, fewer of them will move, since there's a high risk that the new job won't be as good.

I agree but I was just pointing out that it's almost inevitable for some developers to leave the organization for reasons beyond the control of people running the org and therefore it is not worth it to have the org undergo a cultural transformation and turn it into a fraternity just to dissuade them from leaving.

You can start by not inventing insulting nicknames. If you are in an at-will relationship you risk the other part leaving at any time, and you really shouldn't complain about it.

> try something new every couple year and get a kick out of it

Or it's the only reasonable way to get a decent raise. Staying at one job for too long can end up losing you a lot of money in the long term, unfortunately (and make it harder to get a new one when you decide to go looking).

Let them leave. They'll leave anyway.

The author assumes that you'll lose engineers in about 2 years if you don't keep coding fun and he assumes that trying new things when coding is fun.

If you agree with those two assumptions, then the guess it is a good value proposition he proposes.

Even if you accept that, the cure may be worse than the disease. You'll lose programmers in under 2 years if they have to maintain a mishmash of learn-as-you-go style code with multiple quirky build and deploy systems, which seems to be a common result of the "write it in a new language" attitude.

When you're learning a new language you usually end up with unidiomatic code, and can't use the language tools effectively yet. The most "exciting" languages may not even have a stable tool set.

quite. It seems to be the curse of the era that the techies are constantly chasing the "shiny". It seems that the web, through the likes of PHP and JS, has turned "programming" into a form of self expression. That the language used etc is supposed to say something about the programmer as a person.

Because developers are usually "let go" before management or sales, they have to keep their skills up to date in order to get their next gig. That's where the shiny comes in. Shiny gets hired. Dull doesn't.

The problem is when those developers _only_ want to work on shiny. Developers need to understand that they need to work on maintenance projects as well.

The other perhaps more prominent issue with Javascript in particular is that the new thing often dies quickly, so then you need the next new thing.

> In a professional environment, we develop software not because it's fun, but because it supports the business and/or because it is the business.

Software is created, knowledgeable developers get bored if you don't take their needs into account, they quit, software dies, sometimes slowly enough for the business to not even notice, sometimes fast enough for business to die too.

I don't see how ignoring the problem, of developing software not being fun, does anything but harm the business.

The quote is missing important context. Just want to clarify that author is speaking about microservices specifically. The whole point of microservices is that one could be rewritten in a matter of days without involving substantial risks and expenses.

The cost of managing microservices and whether multilingual environment pays off is a separate question. Rewriting a now much better understood solution using an appropriate technology could have dramatic effect.

> But I feel that the author largely fails to see the business perspective.

I wouldn't say that is necessarily true, given the solutions he proposes. While I do think the article is laden with naïveté, his proposed solutions at least seem to factor in the reality that costly rewrites are a problem. He's finding ways to minimize that cost.

I think you're taking that quote out of context. Right before that, the author indicates that he's talking about micro-services, so ideally a complete from-scratch rewrite of a single component wouldn't actually be a very big project.

Reply on news.ycombinator.com