11–20 of 114 posts
> how to organize software so that the complexity remains manageable as the size increases So John is missing the role of software architect here. Science, art, and development - 3 roles. Not all visits to the stratosphere are misadventures.
Earlier quoted context omitted.
>"it seems to work and we don't dare change it" What they mean is: "we don't understand it and we don't have good tests, so there is a high probability that it doesn't work and that doing even the most trivial and seemingly harmless modification would cause an issue to surface, so we don't dare to change it else we wouldn't be able to pretend that it works anymore and might have to fix a lot of issues that we would h…
Yeah.. The dumb thing is that it isn't even _that_ hard to fix this kind of stuff... It does take time and commitment though. But _hard_? No.
I think you (and many software developers) are using the word "hard" to mean "intellectually challenging", as in "Leetcode Hard". But things that require a lot of effort, time, and coordination of people are also hard, just in a different way.
Imagine a codebase with a wart. And yes, without enough tests. Let's say the wart annoys you and you want to fix it. But first you have to convince your employer to let you spend 6 months backfilling missing tests. In the meantime they will pay your salary but you will not work on the features they want. You will be working on fixing that wart. Convincing management: easy or hard?
OK, so you got them convinced! Now you can't just fix the wart. First you have to slog through a big refactor and write a bunch of tests. Staying positive while doing this for 6 months: easy or hard?
Do you stop other teams from writing more code in the meantime? No, so does the new code come with tests? How do you make sure it doesn't depend on the old "warty" interface? You need a compatibility layer. You need to convince other managers to spend their teams' cycles on this. Easy or hard?
OK, the refactoring is done. You release the new software. But, despite all your efforts you overlooked something. There's a bug in production, and when a post mortem is done - fingers point at you. The bug wasn't introduced in pursuit of a new feature. It was part of an effort to solve an obscure problem most people at the company don't even understand. To them, the software worked before, and it doesn't work now, and it's always those nerds tinkering with stuff and breaking things. Convincing these people to let you keep your job: easy or hard?
Perf review time. Your colleague shipped a new feature. You shipped... that thing that broke prod and nobody understands. Getting a raise: easy or hard?
And that is why these warts fester. The end.
One thing that’s missing: programs are mutable. A good programmer writes programs that are easy to maintain and extend.
This reminds me strongly of reaching the final year industry projects in my software engineering degree, and seeing a significant portion of my colleagues unable to develop software in any meaningful way. There was a curriculum correction in the years afterwards I think, but so many students had zero concept of version control, of how to start working on a piece of software (sans an assignment specification or scaffo…
Is that unique to software though? Plenty of people can follow a plan but still find it tough to start from first principles, I would think.
Earlier quoted context omitted.
>"it seems to work and we don't dare change it" What they mean is: "we don't understand it and we don't have good tests, so there is a high probability that it doesn't work and that doing even the most trivial and seemingly harmless modification would cause an issue to surface, so we don't dare to change it else we wouldn't be able to pretend that it works anymore and might have to fix a lot of issues that we would h…
Yeah.. The dumb thing is that it isn't even _that_ hard to fix this kind of stuff... It does take time and commitment though. But _hard_? No.
At some point I was working on a piece of software we knew inside out, had good tests for and often ran through hand curated stress tests for benches, analysis or just exploratory testing, so we had a high confidence in it and in our ability to modify it quickly and successfully.
Some day executives were visiting and we had to do a demo of our system interacting with another one. Until the last minutes we were happily modifying our code to make the demo better. A guy from other system's team saw that, freaked out, and went straight to our boss, who then laughed with us at how scared the guy was. It turned out his team was not at all that confident in their system.
When I was a prof (many years ago), I was working on a database for a political campaign. The code was a mess. I asked a couple of my colleagues (successful comp. sci. profs) to help out. It became clear very quickly that there are two kinds of comp. sci. profs: those who can program and those who cannot.
I can definitely write a 1KLOC program to solve a 10-line problem.
Earlier quoted context omitted.
>"it seems to work and we don't dare change it" What they mean is: "we don't understand it and we don't have good tests, so there is a high probability that it doesn't work and that doing even the most trivial and seemingly harmless modification would cause an issue to surface, so we don't dare to change it else we wouldn't be able to pretend that it works anymore and might have to fix a lot of issues that we would h…
Yeah.. The dumb thing is that it isn't even _that_ hard to fix this kind of stuff... It does take time and commitment though. But _hard_? No.
If it's in a professional setting, it's most likely to not be a hard problem, but actually an impossible one.