Unsophisticated software development
updated 3 months ago; latest suggestion 4 months ago
Simplicity is prerequisite for reliability. -- Edsger Dijkstra
This talk is about the drawbacks of (over)sophisticated software design and implementation. It recalls to hold off from overengineered stuff and reminds us to better write clean, understandable code that does not surprise anyone (POLS/KISS).
Large scale software projects tend to become harder and harder to maintain. I'll show real-life pitfalls of my own experience in large scale projects (ea. >5 years running time and >50 developers) in different languages like C++, Java and C# (and also a little Swift :-). These samples include (but not restricted to): How over-adoption of the newest language features cause unforseen side effects at customer site; how "astrally" architecture intended to last for decades emerges to be so overengineered that nobody understands it; how highly sophisticated self-made funky language "extensions" are soon out-dated by newer programming language versions.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand. -- Tom Van Vleck
Dear 8c88..6da4, yes, it's a joke. I assumed it was clear :-)
It's almost always either performance or memory pressure/shortage that require "clever tricks".
It definitely makes sense to me that keeping code simple is, in general the best way to reduce technical debt, and I'd like to see this talk and hear about real examples. However, I take objection to the quote at the end. This is a joke, right?
Real programmers don't comment their code. If it was hard to write, it should be hard to understand. -- Tom Van Vleck"
There are plenty of instances where code is necessarily complex, and requires documentation to explain, and perhaps the talk should also highlight places where this is acceptable? (Performance, for example is one of the main reasons that ridiculously convoluted code is written)
Boo! Formatting! Let's try that again…
- "understandable code that surprises no-one"
- "non-foreseen" => "unforeseen"
- consider "how architecture intended to last for decades" instead.
Some additional suggestions: * "understandable code that surprises no-one" * "non-foreseen" => "unforeseen" * consider "how architecture intended to last for decades" instead.
Really great. I think it's a great proposal. I hope you get to present it.
Hi 8b2f...154, thanks for your comment! I updated the proposal; hopefully it's easier to understand now.
I think there's a great idea here, but you're hiding it behind difficult to understand writing. I'll admit I've only had one cup of tea so far this morning, so maybe it's me, but I'd radically simplify the proposal to focus on the meat of your idea: keeping code simple so it's easy to understand, because "reasons".
There's great source material out there for juicy quotes. I'm sure you could find some from industry luminaries to illustrate almost every point.
This could be one of those talks every developer is required to re-watch annually just to prevent over-complexity creeping into their code. (I know I'm frequently guilty.)