undefined | Better HN

0 pointsdeltasixeight4y ago0 comments

>This is your problem, right here.

Nah. There's no problem here. This is the most common behavior in any place corporate or not. Humans resist change. However specifically for corporations, it is very very very rare for a company to allow a rewrite because of two reasons: First the company is often way to busy with creating features and solving problems then to do a code rewrite. Second it is in direct conflict with the bottom line. Business people don't see the necessity so there is huge resistance.

When a company allows a rewrite it's 99% of the time only to serve a new feature or fix a flaw that no longer can be ignored.

>Premature modularity is a poor man’s substitute for simple-then-refactor.

Do you have any evidence to back up your claim or is this just your opinion? Using words like "poor mans substitute" doesn't lend any credibility to your claim. For example I can say the opposite and we can go in circles forever: Writing unmodular code is a garbage technique only done by junior developers who can't abstract things and by a good number of senior developers who've never learned how to code properly in a modular way. These guys don't even understand the true meaning of a module.

See what I did there?

0 comments

josephg4y ago

> There's no problem here. This is the most common behavior in any place corporate or not.

Its hard to say statements like that universally because it really depends on where you work (and have worked). There are plenty of places which make time to refactor along the way, in small and large ways. Its good engineering, and a healthy code base nets better long term outcomes for the business too. Business people care about the team's velocity (since programmers are expensive). And I'm disheartened you think its the norm but not all companies have MBAs telling software engineers how to do our jobs. (Eg, Google / Facebook / Netflix / Github / etc.)

> Do you have any evidence to back up your claim or is this just your opinion?

Its just my professional opinion, backed up by almost 30 years writing software at all sorts of companies and in all sorts of environments. But no, I wish we had quantitative evidence for this stuff. But there's a weird dearth of quantitative research around software engineering. We as an industry don't really know what we're doing yet. I'd love to read some studies on this stuff if you can find any.

But I'm very confident about what works best for me, from trying lots of things on solo projects. I'm way more productive when I throw something together quickly, iterate like mad on how it works internally, then tidy it up and modularize as I get more confident around the best way to structure the code. Whenever I modularize up front I basically always end up regretting my abstraction boundaries - and either have to rework them (which is expensive) or I leave them alone, and just ship vaguely mediocre code.

But if prematurely modularizing your code is the only way you can modularize anything at your workplace then - well, you do you. But I find that pretty sad.

deltasixeightOP4y ago

>universally because it really depends on where you work (and have worked). There are plenty of places which make time to refactor along the way, in small and large ways. Its good engineering, and a healthy code base nets better long term outcomes for the business too.

And I have worked in places where people know the exact formal definition of modularity and they modularize things correctly so such refactors never need to happen. I've worked and have experience in enough places to know that both a place where people understand true modularity and a place where people constantly refactor their designs on the regular are incredibly rare. My sample size is large enough for me to confidently say that your view point is highly highly inaccurate. Your experiences are in the minority of the minority along with the experience of working at any company that actually properly understands modularity. Understanding modularity is more of an individual thing.

The only time where I have been at a company that allows you to write shitty code and constantly refactor it are Big companies that have tons of low impact useless projects. Get on the project that is on the critical money path and all your luxuries of refactoring shitty code disappear because actual business realities influence the process.

>Whenever I modularize up front I basically always end up regretting my abstraction boundaries - and either have to rework them

This is because you lack knowledge about modularization and what should be a proper abstraction boundary. Almost know one knows what this properly is. You know the design pattern book by the GOF and every derivative book on that topic? Read it and then know that it's completely and utterly wrong. If you abstract things using traditional techniques and "art" and "experience" like this you ARE not making your code more modular.

>But if prematurely modularizing your code is the only way you can modularize anything at your workplace then - well, you do you. But I find that pretty sad.

You have a lot of confidence, and it's a subtle derogatory jab by saying your sad as if you're superior to me. Literally you're implying your sad that I can't rise to your level of "superiority." Get off your high horse. Have you ever thought of the possibility that you actually lack knowledge on something? That you've never actually properly abstracted things?

j / k navigate · click thread line to collapse