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

How boring should your team's codebases be

blog.meadsteve.dev

Post reply on HN
Print view View original

141–150 of 235 posts

Re: How boring should your team's codebases be

#141

Post by paulryanrogers »

andrewstuart wrote: post #96

Here’s a question for you: “To what extent should developers use advanced programming language features?” I worked on a project once that had lots of sophisticated code in it. One of the senior developers objected however when I suggested we use typescript decorators. He said other developers might not understand it. Consider what happens when the question is phrased differently: “To what extent should developers use…

Some features are more naturally intuitive than others. Consider an 'if' statement and a monad. How much talent is available that's capable of understanding and using the latter effectively? How much time would be needed by a new hire to come up to speed? If you need intermittent help from contractors then will they be able to hit the ground running?

Over time the bar does rise, and I hope that trend continues. Yet it's undeniable that there are limits like human lifespan, and how much people and companies are willing to invest in education and training before doing the actual work for which they're compensated.

Re: How boring should your team's codebases be

#142

Post by steveBK123 »

lr4444lr wrote: post #117
geokon wrote: post #70

Earlier quoted context omitted.

Isn't the moral of the story that you didn't charge for it correctly? If you charged a fixed annual maintenance fee then you would have felt very clever having made a ton of money not having to do anything Administrators would have also felt good that they had you as insurance of sorts bc the way things stand you make no money and can disappear at any moment

I think they would have still been uneasy that he was a SPOF, even if he had charged a lot more. And there's also a cognitive disconnect if a one-man deliverable costs above a certain threshold.

The SPOF fallacy is always managements favorite way to waste money. My current shop we had a system maintained by 1 guy, as like 10-20% of his job/time. I can guarantee you he is not paid even $500K.

This of course was deemed bad & risky, so we must engage a set of vendors to deliver a replacement. 2 years, a dozen subcontractors, and 7-figure annual bill later.. and they still haven't replaced 10-20% of this SPOF. Literally spent $5M so far against max $100k of this guys salary. There are still no signs that SPOF can give up the responsibility even next year.

No one has been fired over this. In fact the decider has been promoted.

Re: How boring should your team's codebases be

#143

Post by samatman »

lr4444lr wrote: post #117
geokon wrote: post #70

Earlier quoted context omitted.

Isn't the moral of the story that you didn't charge for it correctly? If you charged a fixed annual maintenance fee then you would have felt very clever having made a ton of money not having to do anything Administrators would have also felt good that they had you as insurance of sorts bc the way things stand you make no money and can disappear at any moment

I think they would have still been uneasy that he was a SPOF, even if he had charged a lot more. And there's also a cognitive disconnect if a one-man deliverable costs above a certain threshold.

Both of these issues are often solved by incorporation.

A one-vendor deliverable can cost whatever, and corporations can certainly agree to keep supporting something for a certain time.

Doesn't actually matter if the corporation has one member, and no coherent plan for what happens to the contracts if that person steps in front of the wrong bus. It makes the relationship legible in the way that the contracting party is comfortable with.

Re: How boring should your team's codebases be

#144

Post by bdg »

paulryanrogers wrote: post #135
bdg wrote: post #107

Earlier quoted context omitted.

I think I grossly oversold this thing because there's a lot of comments here asking for something. I don't really have this concept written down anywhere like a number of other ideas I have. But, I guess the short version is, if I had to make an elevator pitch or something: No framework is a configuration (maybe "distro" in the linux sense) of concepts (maybe "packages" in the software sense). A concept is either som…

Feels a lot like a framework to me, albeit it more by convention and enforced by linters instead of skeletal code. And a fairly rigid one at that. Has this been tested against a more traditional architecture to solve a similar business problem? And if so what were its cons?

> Feels a lot like a framework to me, albeit it more by convention and enforced by linters instead of skeletal code

100% Yes, and the linters are just an experiment I had to see what was possible in terms of "packaging a no-framework framework for distribution".

> And a fairly rigid one at that.

The same problem exists when using a framework. You use the framework's rigid rules and tools or you don't.

> Has this been tested against a more traditional architecture to solve a similar business problem? And if so what were its cons?

I don't know what you consider to be "this" because there's multiple concepts at play in my previous post: (i) "no framework", (ii) the specific "Modular Provider Architecture" ruleset, and (iii) python architecture linter.

What you are looking for in an "against" case? What is a traditional architecture?

Re: How boring should your team's codebases be

#145

Post by forsakenkraken »

jiggawatts wrote: post #22
bdg wrote: post #16

Earlier quoted context omitted.

I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?

> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…

Just to agree with the OP, I've just gone through a government tender process to buy a piece of software for my organisation. The number of people who could bid on the tender was incredibly limited. We've ended up with a 'solution' where the best and cheapest company was excluded from bidding. Mainly cause they struggled with our byzantine tendering process, that gives us 'best value' according to our procurement team. It's not the only broadly failed IT system that we have which has gone through these processes, so it's not a one off either.

We're currently busy throwing away solid pieces of open source software that have worked well for years in favour of enterprise garbage.

Re: How boring should your team's codebases be

#146

Post by steveBK123 »

listenallyall wrote: post #91
jiggawatts wrote: post #22

Earlier quoted context omitted.

> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…

I think most readers, including myself, empathize with you and understand the frustration and absurdity. But you are also telling just one side of the story (yours) and I imagine that v.2.0 specs had certain requirements and features, possibly required by legislation, that needed to be followed and implemented. When you say, dismissively, There are rules, you see? They have to be followed! that's when I, and likely o…

No this is really how stupidly it works. Government software consulting is insane.

The licensing/certification stuff basically creates monopolies.

My spouse worked at a digital agency a decade ago, that it turned out was basically a near-monopoly provider of certain types of software for the local government.

The thing was, none of the work was actually done by them. It was all subbed out to 3rd party dev shops who couldn't qualify themselves for the required licensing. Further, they subbed out all the dev offshore.

So the government was both overpaying for offshore devs, and thinking they were spending money locally because the intermediary happened to be local.

They could have gotten the same work for 40-50% cheaper just skipping the front company, or spent the same and hired actual local devs they thought they were.

Re: How boring should your team's codebases be

#147

Post by steveBK123 »

norwalkbear wrote: post #129
jiggawatts wrote: post #15

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…

Yea government work is full of that. Kickbacks galore, my brother works in ed-tech. He said one state rewrites their public school report card system every two years like clockwork because of that.

You know the crazy thing is that moderately sized private companies I've worked (500-5000 people) have plenty of that kind of BS.

I have seen a piece of mediocre software or service vendors sold as a panacea to my last 2 shops, skip POC phase and just get purchased off the back of someone (not in IT) very very senior being buddies with the founders. No users or technical people were asking for it.. just gets rammed down from place up high until a reasonable enough niche is found to put it into PROD.

It ends up being a solution in search of a problem, with a couple years finding where to use it, a couple years finding it inadequate, and then a couple years removing it again.

Great money if you can get it.

Re: How boring should your team's codebases be

#149

Post by ryanbrunner »

I think something that has served me well with these decisions is only considering novel tech if it does a better job of solving a problem we have right now. If the problem can't be measured yet, it's not worth working on yet. Start with something that is as boring as possible, it'll become obvious pretty quickly where the pain points are, and consider doing something novel for those.

Re: How boring should your team's codebases be

#150

Post by porker »

berkes wrote: post #72
porker wrote: post #56

Working on a not-yet-launched Web app, where the backend and frontend both use CQRS, and hoops are jumped through in the name of "purity", a more boring codebase would be appreciated. Velocity would be higher and new hires onboarded in less time.

But the two main questions are: Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? Boring doesn't have to be big-ball-of-mud, but the architectures you mention exist exactly to avoid big balls of mud from growing. And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate state…

> Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt?

So far there are zero clients and multiple pivots. The boring alternative needs only to yield higher velocity to be worthwhile, otherwise funding runs out before market fit and the current architecture achieves zero.

> And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data?

Everything is stored in a popular RDBS. CQRS makes logging all data changes easier, but that is the only time intermediate states are used. If we did event sourcing I'd be keener on the architecture.

Post reply on HN