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

Kernighan and Pike were right: Do one thing, and do it well

medium.com

Post reply on HN
Print view View original

151–160 of 256 posts

Re: Kernighan and Pike were right: Do one thing, and do it well

#151

Post by ahtihn »

prakhar897 wrote: post #112
ahtihn wrote: post #104

Earlier quoted context omitted.

You let interns push to production without code review?

Totally missed the point. Even with Code reviews, Unit/Integration Testing, Automated CI/CD and more can a person broke the prod. One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. If you think "why not restrict config actions" etc, it's because the dev can go there and tweak those actions too. And e…

> One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.

So you don’t have a staging environment to check config changes before deploying to prod? Or you don't put k8s manifests (or helm charts or whatever)in source control and just update prod through CLI? And you let interns do it alone?

Your problem isn't interns, it's a terrible deployment processs with weak controls. Even senior engineers are going to break prod regularly in conditions like that.

Re: Kernighan and Pike were right: Do one thing, and do it well

#152

Post by baz00 »

sph wrote: post #138
baz00 wrote: post #102

Earlier quoted context omitted.

There is so much wisdom in here. Fundamentally, don't make life hard for yourself, or others.

When a company measures developer productivity in code added and feature delivered, it creates a perverse incentive that attracts people that really love to write a lot of code and building mountains out of molehills. The best engineer (and not only, see that famous quote by Kurt von Hammerstein-Equord) often is the lazy one. It was a known notion that somehow disappeared around the turn of the millennium.

Indeed.

We're still around. We're just so far up the hierarchy now that the wisdom can't be pushed down easily.

Re: Kernighan and Pike were right: Do one thing, and do it well

#153

Post by baz00 »

dgb23 wrote: post #137
baz00 wrote: post #92

Earlier quoted context omitted.

This. So much this. We are 5 years into a microservices wank-fest. So far the net ROI is negative, the user experience sucks more than ever, the complexity is so high that people can't get things done, nothing works properly any more and no one owns anything because they have washed their hands of it all. But this is still promoted as a success because no one wants to be accountable for the fuck up. Our team spend mo…

One thing I wonder is this: There are companies that are very successful and have split their service architecture into domain entities, called microservices. Are they successful because or despite this decision? Is both true in some sense? A more natural way to split up a server architecture is to use computational boundaries. These are found by thinking of how data is processed and flows through the system as oppos…

There are successful companies that this model applies to. But the problem is that they are outliers.

The biggest problem with the whole IT industry is seeing outliers promoted as the successful path and people taking on faith arguments for technical decisions instead of rational decision making processes.

Re: Kernighan and Pike were right: Do one thing, and do it well

#154

Post by saghm »

tailspin2019 wrote: post #6

Good article, but to me it seems to be co-opting the term enshitification in a strange way: > Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed. I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. It doesn’t necessarily emerge “bottom up” as the result of technical d…

Am I the only one who thinks that the term sounds far too general given the apparently narrow interpretation that's intended by it? When first seeing the word, it literally just sounded like it meant "the process of becoming shitty", and I never would have guessed that it was intended to be so specific. It seems unfortunate that the term was picked primarily for how evocative it is rather than for its clarity.

Re: Kernighan and Pike were right: Do one thing, and do it well

#155

Post by qaq »

lijok wrote: post #61
qaq wrote: post #59

Earlier quoted context omitted.

Have your teams use façade pattern and you no longer need microservices to "isolate it"

Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc

Yep and people you do not trust should not have access to CI/CD workflows and repo settings. Your CI/CD workflows should prevent everything else you mentioned.

Re: Kernighan and Pike were right: Do one thing, and do it well

#156

Post by baz00 »

wazoox wrote: post #143
baz00 wrote: post #92

Earlier quoted context omitted.

This. So much this. We are 5 years into a microservices wank-fest. So far the net ROI is negative, the user experience sucks more than ever, the complexity is so high that people can't get things done, nothing works properly any more and no one owns anything because they have washed their hands of it all. But this is still promoted as a success because no one wants to be accountable for the fuck up. Our team spend mo…

The code reflects the organisation, that's one of the laws of computing (Fred Brook's law maybe?). Microservices work well in a sufficiently large org, with autonomous entities working on different parts of the system, extremely well-defined interfaces between the services, and someone high up having a bird's eye view of the system. If your organisation doesn't look like that, you can only fail at microservices. Eith…

This is one reason I am an opponent of microservices generally. Every organisation I've worked for is made of shit and straw bound together with a solution of piss. ergo a monolithic crap pile is were they should aim.

Plus it's easier to run a hundred monoliths than it is to run 100 services. This is on the basis that running 100 instances of something the same with no inherent complexity in each instance is much easier to automate, build and manage than 100 things that are different and have to talk to each other.

Re: Kernighan and Pike were right: Do one thing, and do it well

#157

Post by qaq »

prakhar897 wrote: post #97
qaq wrote: post #59

Earlier quoted context omitted.

Have your teams use façade pattern and you no longer need microservices to "isolate it"

Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.

Sure with proper CI/CD in place which you need regardless of app being a monolith or a set of micorservices. It's also infinitely simpler to setup proper CI/CD for a monolith.

Re: Kernighan and Pike were right: Do one thing, and do it well

#158

Post by tailspin2019 »

gumby wrote: post #150
tailspin2019 wrote: post #6

Good article, but to me it seems to be co-opting the term enshitification in a strange way: > Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed. I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. It doesn’t necessarily emerge “bottom up” as the result of technical d…

> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. The other two important criteria implied by this new term are that it is deliberate and that it is taken for the benefit of the “author” (company) at the expense of the user. Bugs are inadvertent and have no intent so don’t match either criterion. Google’s so-called “integrity” system is DRM for the benefit of…

> The other two important criteria implied by this new term are that it is deliberate and that it is taken for the benefit of the “author” (company) at the expense of the user.

> Bugs are inadvertent and have no intent so don’t match either criterion.

Yes, good distinctions. Very different from inadvertent bugs or routine technical debt.

Re: Kernighan and Pike were right: Do one thing, and do it well

#159

Post by jmclnx »

cpach wrote: post #74
throwaway31381 wrote: post #68

Earlier quoted context omitted.

I don't believe GNU's triumph over the BSD derivates was for the most part technical, they just happened to be at the right moment at the right time to ride along Linux's success. A consequence of the proliferation of arguments in the GNU tools is imho that it made the GNU manpages too verbose and information dense to the detriment of their usefulness.

Good point. However: The users could have revolted and gone to *BSD land instead. But for some reason, most users didn’t.

That is because of the "lawsuite", unless you are referring to the 80s.

Back then, Companies and Colleges were the ones who got UNIX. Companies went with AT&T, and IIRC Colleges when with BSD. So AT&T won out due to better financial backing and maybe a possible threat of AT&T going after BSD.

Re: Kernighan and Pike were right: Do one thing, and do it well

#160

Post by dgb23 »

i_don_t_know wrote: post #42

To me, Wirth’s Oberon system has the same philosophy of having small composable tools and being extensible. There’s no distinction between system language and scripting language. Text is also a common way of passing data, but you can use whatever data structure you want. I think of it less as an OS than as an application shell that you shape to your needs.

There are very different notions of OS and what its responsibilities and capabilities should be.

In the world of Lisp and Smalltalk, you have a holistic view of what computation means. In Unix, complexity is pushed outward.

Web browsers, language runtimes, virtual machines and containers are all examples of people expressing their needs by simulating operating systems.

Post reply on HN