“We should rewrite it all,” said Pham.
“It’s been done,” said Sura, not looking up. She was preparing to go off-Watch, and had spent the last four days trying to root a problem out of the coldsleep automation.
“It’s been tried,” corrected Bret, just back from the freezers. “But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it.” Trinli grinned evilly. “And guess what—even if you did, by the time you finished, you’d have your own set of inconsistencies. And you still wouldn’t be consistent with all the applications that might be needed now and then.”
https://www.goodreads.com/quotes/9427225-pham-nuwen-spent-ye...
When I was a kid, my first computer had 4k of RAM; my next one had 48k. I learned a lot about how everything worked, because there was very little to it. Over the years things have grown, but I've had a chance to grow along with it.
But somebody starting out today start in the middle of vast layers of complexity. From processors and hardware that are hugely more complicated up through virtualization, containerization, rich OSes, languages and standard libraries with decades of history, tons of add-on libraries, and then out to user platforms with their own tangled ecosystems and decades of history. It's a lot!
I think it's so much harder now for developers to develop "mechanical sympathy", that intuitive understanding of the rhythms of machinery. Apparently slight shifts in code can be 3 orders of magnitude difference in performance. So much of what they deal with is historically determined. (E.g., what percentage of working developers has every actually seen a carriage returning or a line feeding?) And it's all running on much shorter cycles with an ever-updating mass of tools, libraries, frameworks, and operating systems.
On the one hand, people can do some amazing¸valuable stuff with very little training. That's great! But I think it's a lot harder to truly master the craft, and I'm concerned that a lot of programmers spend their time in professional contexts where the feedback loops are long or broken such that they are encouraged to be less analytical than superstitious, cargo-culting their way to from one overly-aggressive sprint deadline to the next.
This has always been something that’s fascinated me, how some people don’t have this feeling of “mechanical sympathy”.
Feeling “bad” (not the exact right term but I don’t know how best to describe this very intangible feeling) for a high-revving engine, or a CPU wasting cycles, or a structural component being under too much stress. Even if all of those things are within spec.
It feels like the drive to avoid that feeling ends up creating better solutions: more efficient code, a better distribution of stress across a structure, etc.
But I wonder if it’s something learned, or something that people just “have” to a certain degree. Not trying to pathologise everything, but it feels like the sort of thing that would be correlated with ASD
However, we have to set ourselves up so that it's easy to learn. With my early gear, I could hear it. Hear the disk seeks. Hear the bits streaming down the wire. I could see it via the blinkenlights.
In recent years, I've had to activate it, even build it. E.g., at the top of my screen I've got mini graphs of CPU, RAM, net, and disk activity. I'm constantly re-confirming and re-challenging my intuition of what's going on. And with distributed systems, I find various ways to keep feeding myself the sort of data that, over time, turns into intuition.
And that's so hard these days! Not sure how fresh-out-of-college developers are developing those intuitions, but I hope they're finding ways.
Whatever challenging "science" aspect I was expecting from my "computer science" skills just doesn't seem to exist. The concerns of logic and program efficiency/structure are still important, just not what I have to do most of the time when gluing stuff together. I'm trying to accept my fate these days and just be thankful I work in a well-paid field with good people, but it's tough as I feel it does affect my overall performance and personal enjoyment as flow is so hard to achieve anymore.
I am guilty as the next guy of throwing stuff that "just works" out there.
It is also important what kind of software you write - if you write frameworks, you better get unit tests and full blown process in place to make sure your framework will work in 10 years time.
If you work on a business application - in 6 months time your application might be gone or requirements change in a way that everything you wrote does not matter anymore and future proofing was just a waste of time.
I would like that more devs/software engineers understood which one they are writing.
I'd say if you write code with the assumption this might be true, you're almost guaranteeing it will be - business requirements do often change but typically that means having to modify/refactor existing code so that core components continue to work the same way, because those core requirements haven't changed. While you can make occasional assumptions about which requirements are more likely to change than others I'd much rather write all my code on the assumption the requirements won't change too significantly and that the tools/automated testing and other processes are in place to support that. There's far too much "throwaway/POC" code that ends up getting used in production, often for years, then mysteriously stops working down the line because nobody ever assumed it would need to survive that long. Whereas I don't believe I've seen a project fail because too much time was spent ensuring code was well written and well tested.
This does indeed happen. Kent Beck tells a story of being called in to help a European insurance project where, sick of all the legacy code, they spun off a new company to start fresh. Teams of bright people spent years building The Right Thing and doing it The Right Way. But they never delivered anything actually useful, and by the time the sponsors were entirely fed up, they still couldn't promise anything soon. So they fired everybody, hired back one team's worth, and then started fresh on well-written code that actually did something immediately useful.
I think there's a middle path between "write garbage that succeeds" and "write perfect code that never gets used". I think it's narrow but doable, and it requires dogged attention to both "ship early and often" and "build in a way that's sustainable over the long term".
"write perfect code that gets used a lot, frameworks, libraries"
"write throw away glue code with use of libraries and frameworks"
Because for me "write garbage that succeeds" vs "perfect code that never gets used" is false dichotomy.
Where most devs want to write libraries and frameworks because these are places where "eternal fame" is - even better if you can write your own programming language that is the highest echelon of software engineering.
Ugly truth is most devs are driving beat up honda - where Linus Torvalds, Anders Hejlsberg, Bjarne Stroustrup are F1 drivers - you can rev up your honda on street lights all you want - but that is not the same league.
So most devs write business apps and many of them overshoot quality.
I think this can be true for sufficiently bad definitions of quality, which I agree are very common. To me, though, overengineering something doesn't really increase quality, because actual need puts an upper bound on quality.
But if your notion is that there's no place for throwaway code, I disagree. The trick with throwaway code is to actually throw it away. Temporary and permanent code, used appropriately, are both vital to projects that are resilient in the face of real-world circumstances like lack of certainty and changing needs. It's the third kind you have to watch out for: https://web.archive.org/web/20190709091156/http://agilefocus...
Oh I definitely have. In fact I'd wager that it's the leading cause of failure for programmer lead startups. It's far too easy to spend time worrying about code and ignoring the business when your skillset lies in code and not in business.