For my friendgineers
  • Articles
  • Categories
  • About
  • Mastodon
  • Github
  • Twitter
  • LinkedIn
  • RSS Feed
June 19, 2019 by Leon Rosenshein

Correctness Vs. Change

https://www.infoq.com/articles/correctness-versus-change/

About Me

Leon Rosenshein

Helping my Friendgineers whenever possible

Latest Articles

  • New Code Vs. More Code
    Just like the code we write is going to be read far more often than we write it, the amount of code we change/extend is MUCH higher than the amount of code we write from scratch. So don't forget, when writing code, you, or someone you know, is going to have to extend it. So be prepared.
  • Listen to Your Data
    Your data can speak volumes to you. If you know how to listent to it. And are willing.
  • What Is Performance Anyway?
    Performance is more than sheer top speed and power. Before you can call something high performance, you have to know what you mean by performance.
  • Time Passes
    Unit tests should be idempotent. No matter how many times you run them, or when you run them, they should always give the same answer. If they don't, something is wrong.
  • Licensed Engineers
    It is possible to be a licensed software engineer, but almost no one has bothered. License or not, it's still Engineering
  • Engineers Estimate
    Engineers all make estimates. Some are good, and some aren't. That's hardly unique to software engineering. Just another way software engineering IS engineering.
  • Constraints
    The primary job of an engineer is to balance competing constraints to provide value. This is done via a deep understanding of the problem space, the available tools, materials, technologies, and processes, and the requirements. That's what engineering is.
  • Slow is Smooth, Smooth is Fast
    Sometimes you have to accept two contradictory things as true. But what if they're not as contradictory as you think? What if it's just your perspective that makes it look that way?
  • Government Digital Services
    You don't necessarily expect state of the art reccomendations from a government website, but if you try sometimes, you find, you get what you need.
  • Best Simple System For Now
    You can hack together a solution. You can overengineer something and never finish. How do you balance the two extremes? What principles help you find the best simple system for now?

Categories

it-depends (66) context (58) agile (37) systems-thinking (32) learning (31) tdd (30) code-quality (27) career (22) refactoring (21) planning (20) code-for-the-maintainer (19) best-practices (18) martin-fowler (17) engineering-excellence (16) kent-beck (16) testing (16) devops (15) domain-driven-design (15) ownership (15) mmmss (14) decisions (13) software-engineering (12) wip (12) architecture (11) assumptions (11) development (11) yagni (10) bounded-context (9) scope (9) tech-debt (9) book-review (8) code-smell (8) non-functional-requirements (8) documentation (7) geepaw (7) isq (7) naming (7) productivity (7) tyranny-of-or (7) api (6) biases (6) chestertons-fence (6) code-review (6) eisenhower (6) flow (6) hyrums-law (6) life (6) storytelling (6) big-ball-of-mud (5) comments (5) debugging (5) design (5) feedback (5) time (5) tools (5) done (4) goals (4) user-stories (4) autonomy (3) drive (3) hillel-wayne (3) models (3) observability (3) purpose (3) value (3) broken-window-theory (2) change (2) continuous-learning (2) customers (2) dan-north (2) date (2) deming (2) domains (2) drucker (2) dry (2) engineers (2) errors (2) legibility (2) measurement (2) mobbing (2) noestimates (2) object-oriented-programming (2) ooda (2) partners (2) pm (2) priority (2) prs (2) rca (2) readability (2) rubber-duck (2) simple (2) teams (2) tim-ottinger (2) tradition (2) unit-test (2) virtues (2) wat (2) winnie-the-pooh (2)

This page and its contents are copyright © 2025, Leon Rosenshein.

Theme Prav by Pravin Paratey