Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shitlist Driven Development (2016)

sirupsen.com

Post reply on HN
Print view View original

141–148 of 148 posts

Re: Shitlist Driven Development (2016)

#141

Post by randomswede »

Chris2048 wrote: post #67
Macha wrote: post #47

Earlier quoted context omitted.

Go imports are done by direct github URL mostly.

And to personal repos? Yikes. They should learn from the npm left-pad incident..

It is not (quite) as bad as it sounds.

If you have built a module-enabled Go binary yesterday with a specific version of an external dependency, you will get that exact version of the dependency tomorrow when you rebuild (IFF you have version-controlled your go.mod and go.sum, which you should). And if someone tries to be sneaky and move the release tag, the checksum will no longer match, and your build will fail.

If you want to upgrade the version of a dependency, that is doable (with plenty of toll assistance), but it requires a positive action.

Theer is, however, no good solution for the "first use". But, that is pretyt much standard.

Re: Shitlist Driven Development (2016)

#142

Post by Communitivity »

gultig wrote: post #132
reader_1000 wrote: post #78

I don't remember the exact project or where I read it but one project added delay (using sleep function) to depreatected methods in order to discourage people using them. After every release, they increased the sleep time so that at one point it became impossible to use it without noticing it. Although I don't know if it is possible to do this for new code trying to use deprecated function and have old code use non-d…

Back in 2000 we were mandated with a big push to eliminate all shared excel documents and turn them into real database driven products. There was this one department that had a huge excel database that was bringing the network to its knees. Around that time I had discovered that you could create a function in excel with the moniker of a null character (alt-255). We had used that for playing pranks on one another. Som…

I read this, and thought to myself that a hacker would love to find that in code through analysis tools. They could then replace the delay with malicious code, and no one would be the wiser for quite some time.

Doing stuff like this seems creative and awesome at the time, but it breeds vulnerabilities something fierce. It also creates a nightmare for maintenance.

I would suggest a different approach of figuring out how much that Excel doc was costing the company every month, how much the company would save if the doc was converted to a real data service and Web front end, and then present the comparison at a meeting with management from that department - give them a chance to sign on before you take it to more senior management.

Re: Shitlist Driven Development (2016)

#143

Post by Macha »

randomswede wrote: post #141
Chris2048 wrote: post #67

Earlier quoted context omitted.

And to personal repos? Yikes. They should learn from the npm left-pad incident..

It is not (quite) as bad as it sounds. If you have built a module-enabled Go binary yesterday with a specific version of an external dependency, you will get that exact version of the dependency tomorrow when you rebuild (IFF you have version-controlled your go.mod and go.sum, which you should). And if someone tries to be sneaky and move the release tag, the checksum will no longer match, and your build will fail. If…

The left-pad issue is about the package being gone, not modified. Without a cache of your own, there's nothing to prevent that?

Re: Shitlist Driven Development (2016)

#144

Post by randomswede »

Macha wrote: post #143
randomswede wrote: post #141

Earlier quoted context omitted.

It is not (quite) as bad as it sounds. If you have built a module-enabled Go binary yesterday with a specific version of an external dependency, you will get that exact version of the dependency tomorrow when you rebuild (IFF you have version-controlled your go.mod and go.sum, which you should). And if someone tries to be sneaky and move the release tag, the checksum will no longer match, and your build will fail. If…

The left-pad issue is about the package being gone, not modified. Without a cache of your own, there's nothing to prevent that?

That is probably to some extent correct. Although this would bite you on a new build, not for anything that is already running in production. My understanding is that that is/was not necessarily the case for leftpad.

Re: Shitlist Driven Development (2016)

#145

Post by TeeWEE »

adewinter wrote: post #63
Spivak wrote: post #62

Earlier quoted context omitted.

Prod should always be running in allow mode anyway for the same reason that prod builds compile out debug asserts and static type checks. Once the code passes review and makes it into prod you've already lost and spitting out warnings on every function invocation will just piss off your ops team.

Right. So what's the point of having @deprecated tags and a deprecated fail mode if you can't ever use it?

You use it when testing and you can turn deprecation flags on and off. Even on a single production machine/vm.

Re: Shitlist Driven Development (2016)

#146

Post by TeeWEE »

adewinter wrote: post #55
TeeWEE wrote: post #52

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.

If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle. Why not use profanity in code? We're all adults.

You can run tests in deprecation not-allow mode. You can run a single VM in deprecation not allow mode.

I understand that naming features as not supported also makes sense. But to me that is what feature toggles are for.

Re: Shitlist Driven Development (2016)

#147

Post by jholman »

nerdponx wrote: post #73
boojing wrote: post #66

Earlier quoted context omitted.

Your comment made me think of the adage: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live"

Another, less extreme version: "Your most important collaborator is yourself six months ago, and they won't respond to your emails."

The version I've evolved, for teaching students why I care about style:

You need to communicate clearly with a number of coworkers, the most important of whom is future-nerdponx. Sometimes future-nerdponx is smarter than you, and sometimes future-nerdponx is dumber than you, but either way they know where you live, and their misery is your misery.

Re: Shitlist Driven Development (2016)

#148

Post by Uberphallus »

hinkley wrote: post #35
Uberphallus wrote: post #7

Shitlist driven migration/refactor, maybe. If it's development it means you're always deprecating something and that's a significant organizational smell.

If software is organic, and there are limits to growth, how is it that you don’t always have something changing? And why is it an organizational smell?

Maybe we have different views of what "changing" means?

Every software is different, so take my words with a grain of salt, but personally, if it's always changing its behavior/interfaces/architecture (as opposed to just growing or a healthy mix of both) to me that sounds like either:

- It's software that runs with a highly volatile and niche functional target (scrapers, certain bots and business/operation research come to mind).

- It's a snowball of technical debt asking for a rewrite that was never given a green light.

Sometimes an evolution is needed and then shitlists have a place. If you guide development through shitlists it means you always have shit to get rid of. Maybe you have a ball of shit, in that case?

Post reply on HN