Software development quotes
We should all know that products and features need to continually improve to stay relevant for our users over time. And it should come as no surprise that no product or feature is perfect on initial release. They need to be refined over time to get better, incorporating feedback from …
The time elapsed between writing and shipping is the room temp petri dish where pathological symptoms breed and snowball. Longer lead times lead to larger code diffs and slower code reviews. This means anyone reviewing or revising these nightmare diffs has to pause and swap the full context in and …
No, engineers don’t suck at time estimates – and generally speaking humans are better estimators than what most people believe. This seems rather surprising given all we’ve heard about the problems of bad time estimations, projects going overboard, etc and of course, your personal experience with software time estimates. But …
From my experience, successful KPIs follow the following six rules: Rule 1 – A KPI should be measurable. Don’t settle for boolean ‘yes or no’, or something amorphous that you can’t measure. Let’s say that you want to get into fitness. Let me ask you, what does ‘getting into fitness’ …
Before writing code to solve all but the most trivial of software problems, a software engineer should write a tech spec. Some software engineers may regard writing specs as unnecessary process that gets in the way of the agile approach. The point of a tech spec is not to impede …
It’s beyond time we reexamine the post-incident question of luck, and I submit: asking “how we were lucky” in an incident retrospective is not only a waste of you and your colleague’s time, it is distractingly detrimental to post-incident analysis.
