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

Why internal SW is almost invariably sh_t?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Why internal SW is almost invariably sh_t?

#21

Post by P_I_Staker »

pydry wrote: post #16
mattbrewsbytes wrote: post #6

I'm going to use an analogy from my hobby: because internal software is like shop furniture in a woodworking shop. Those things are mostly used in the production of other things that make the company revenue. It does its job, has room for many improvements, but isn't something you'd go out and sell as a product. It might be built from scraps, using crappy lumber and pieced together with whatever fasteners were around…

There are other reasons too: * Time pressure - OSS is rarely under deadline pressure so the temptation to half ass it is mitigated. * Survivorship bias - there's actually a lot of OSS shit out there too but it is much easier to ignore coz nobody is gonna force you to use it.

Similar to your survivorship bias, just because something is done for free doesn't mean it's an insignificant "nothing" project, and just because you sell something doesn't mean much effort was put into it.

You could be comparing the work of hundreds of dedicated engineers for over a decade to something someone threw together in an afternoon, that was never intended for mainstream use... sure they're charging $20k for it, but that doesn't make it "good".

Re: Why internal SW is almost invariably sh_t?

#22

Post by P_I_Staker »

codingdave wrote: post #9
nivertech wrote: post #4

There are so many reasons for this. Here are some of them that I can write without much thinking or checking my notes. 1. Enterprise problem domains are usually much more complex than the ones which are targeted by the OSS. 2. Enterprise problem domains are full of unclear, wrong and even contradicting requirements. 3. Enterprises usually have lots of legacy code/systems. 4. Enterprises usually have lots of glue code…

This list seems to carry a heap of bias with it. Enterprise cares about what works for them, and quick-and-dirty is just fine. Startups care about what works for a broader customer base and need higher quality. Different needs, and different styles. Neither approach is wrong... but they serve different purposes and will appear like cruddy work if you put an enterprise approach into the startup world. And vice versa.…

Worth re-iterating that OP was just explaining the various bias and stereotypes. I think the comment speaks more to perception than reality. There really isn't any good reason to think open source good, closed source bad.

I will say that source control is one area where enterprise is almost total garbage, probably for some of the reasons listed (as well as a lot of unlisted reasons like customers being scared of change). There's probably many other examples where this holds true, and some where it doesn't.

Re: Why internal SW is almost invariably sh_t?

#23

Post by codingdave »

nivertech wrote: post #17
codingdave wrote: post #13

Earlier quoted context omitted.

But how are you defining "equally bad"? Lets ask what it means for tech work to be "bad". If I kept the business working, the tech evolving, while saving the business money and meeting every need it asked, including migration to new tech as the systems aged... which part is bad?

1. Cowboy Coding - means no knowledge transfer, bus factor of 1 - bad for business. 2. Agile Manifesto says "working software over comprehensive documentation", which also leads to information silos and no knowledge transfer, and thus bad for business. Did you ever inherited an enterprise project without any documentation, written in an esoteric language on a proprietary platform, with one-letter identifiers and with…

I think we agree on many things, but your comment makes me feel like you jumped from me being independent to assuming Cowboy Coding. You are assuming that because some enterprise systems are undocumented, that is what every enterprise coder does. The Agile Manifesto also is clear that putting one side above the other does not mean the other is not important.

FWIW, yes, I've taken over horrid undocumented systems... and figured them out, added documentation, and gotten them handed over into sustainable models. On the Agile side, I've been on startup teams that delivered amazing feature sets in a 3 week sprint, and did so sprint after sprint... but I've also been on teams who churned through sprints with nothing to show for it.

I don't think we can boil down a good vs. bad environment, or good vs. bad code, to SDLC processes or enterprise vs. startup. There are good teams, there are bad teams. And matching up the right environment and process to the right team can work wonders. But to be fair, most teams haven't found the right match.

Re: Why internal SW is almost invariably sh_t?

#25

Post by gorjusborg »

heartbeats wrote: post #20
gorjusborg wrote: post #18

Earlier quoted context omitted.

> the amount of hours spent writing the software to B - the amount of hours spent running the software is going to be very low I agree on this point, the amount of time writing software is almost always going to be dwarfed by the maintenance period for software that makes it to production. I've also seen businesses pay a lot of money software maintenance, but you seem to be implying that under-investment is a conscio…

> the amount of time writing software is almost always going to be dwarfed by the maintenance period for software that makes it to production. Oh sorry, I meant it the other way around! So, I mean, I've seen this in scripts that I wrote to "quickly do some stuff". 1. Write the easiest possible implementation you can think of, just string together code in the REPL until it works, then put it all into a .py file 2. Som…

I get what you were saying now... you were talking tooling, not product software.

I agree with your take on the tooling side. No need to gold-plate something that works in the narrow scope it was created for.

Re: Why internal SW is almost invariably sh_t?

#26

Post by m0llusk »

The best software organization I ever worked for had internal tools that still blow my mind in both their features and reliability. Corners were cut in documentation certainly, but the main factors are the quality of the developer teams involved and the nature of their mission. Lots of developers nowadays are under pressure to ship features as quickly as possible for money, and if that is the whole job then of course the results will be spotty and modestly reliable.

Re: Why internal SW is almost invariably sh_t?

#28

Post by closeparen »

Internal users are a captive audience. One of the key functions of middle management in a tech company is to enforce that internal platforms are used wherever applicable, no matter how bad they are or how much internal customers don’t want to, to promote consistency and synergy across the org. Open source is a more competitive landscape.

Re: Why internal SW is almost invariably sh_t?

#29

Post by carlmr »

closeparen wrote: post #28

Internal users are a captive audience. One of the key functions of middle management in a tech company is to enforce that internal platforms are used wherever applicable, no matter how bad they are or how much internal customers don’t want to, to promote consistency and synergy across the org. Open source is a more competitive landscape.

This at least has applied everywhere I've worked. If people choose to use it, it's often a good tool, if people are forced to use it, there's no incentive to deliver.
Post reply on HN