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

Suggestions

  • The proposal author responds 4 months ago

    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".

  • 8c889b136fdf6c994b29f4ad76b8c3b773d36da4?size=100x100 8c889b136fdf6c994b29f4ad76b8c3b773d36da4 suggests 4 months ago

    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)

  • 8b2f2d3e6553c2b4048b93300959895ab76b4154?size=100x100 8b2f2d3e6553c2b4048b93300959895ab76b4154 suggests 4 months ago

    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.
  • 8b2f2d3e6553c2b4048b93300959895ab76b4154?size=100x100 8b2f2d3e6553c2b4048b93300959895ab76b4154 suggests 4 months ago

    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.

  • The proposal author responds 4 months ago

    Hi 8b2f...154, thanks for your comment! I updated the proposal; hopefully it's easier to understand now.

  • 8b2f2d3e6553c2b4048b93300959895ab76b4154?size=100x100 8b2f2d3e6553c2b4048b93300959895ab76b4154 suggests 4 months ago

    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.)