3 ms·

Just to be the old grouchy guy, I can't say that any of the modern processes sound like any fun. 90% of the time I've run into them it was basically a way for

Just to be the old grouchy guy, I can't say that any of the modern processes sound like any fun. 90% of the time I've run into them it was basically a way for external consultants to make a pile of cash (and for an internal champion to work without doing work), the other 10% it slowed down development to a series of small changes. Perhaps it's just a difference in the scope and type of projects (boutique hardware vs. large scale online stuff). Looking back at old codebases that I kept around, we managed to build quite complicated largish systems in a reasonable amount of time using straight waterfall/ad hoc approaches. Simple source control. Simple spreadsheets for bug lists. Admittedly it's hard to avoid attaching particular people to particular blocks of a system, so perhaps making development capable of absorbing random Engineering Resource Units (humans) is the point of all this. ..or maybe it's just that earlier generations of programmers were stupid. I can accept that.

kragen 5y ago
The software process stuff I've found most valuable is really the XP/Joel-Test stuff, not the Scrum stuff: · nightly builds or continuous integration; · pair programming or code review; · automated builds; · comprehensive test suites or test-first programming; · fixing bugs before adding features; · source code version tracking software; · keeping a list of bugs and planned features instead of not keeping one; · prioritizing planned features instead of not prioritizing them; · merciless refactoring to keep the design simple; · DRY, as a criterion for what "simple" means; · "YAGNI" (not writing code to provide functionality that I'm not implementing right now); · a sustainable pace (no death marches); · exploratory "spikes" to explore unknown features; · taking regular breaks; · informal usability tests with prototypes; · standup meetings; · frequent releases; · quiet working conditions; and · retrospectives. I'd add, though these usually go without saying these days: · high-level languages; · interactive development environments, as opposed to the batch-mode approach where you submit a batch job and get back your program output an hour or a week later; · enough testing hardware that you never have to wait for a testing machine to become available in order to get your work done; · using available software libraries instead of not using them. I'm pretty confident that each and every one of these helps me build better software faster, though a few of them may vary somewhat depending on circumstances—I know a guy who can concentrate to write code better in a noisy café than in a private office, frequent releases are at best minimally useful for pacemaker firmware, and you couldn't have written qmail using existing libraries. Also, though, I'm guessing that the old codebases you're looking at with simple spreadsheets for bug lists practiced "working software over comprehensive documentation", "customer collaboration over contract negotiation", "responding to change over following a plan", and especially "individuals and interactions over processes and tools". And those are the core aspects of agile development (though not the Fake Agile we so often see). Some of these are things earlier generations of programmers could only rarely do. If you're working at a company that values processes and tools over individuals and interactions, there's not that much you can do to fix that if you couldn't start your own company; https://news.ycombinator.com/item?id=28670326 https://news.ycombinator.com/item?id=28670326 suggests one reason this is so widespread. Similarly for fixing bugs before adding features, using an interactive computer, having adequate testing hardware, and having quiet working conditions. Source control systems, automated builds, and automated test suites provided substantial benefits to teams that adopted them, but many didn't. That doesn't mean they weren't valuable at the time, just that many people did without. By contrast, I'm less convinced of the value of private offices, written spec documents, schedules, dedicated low-paid testers, scrum masters, planning poker, splitting and merging product backlog items, quantitative task estimation, and even coding interviews.
- aprdm 5y ago
  Great post. Totally agreed.

kragen 5y ago

The software process stuff I've found most valuable is really the XP/Joel-Test stuff, not the Scrum stuff: · nightly builds or continuous integration; · pair programming or code review; · automated builds; · comprehensive test suites or test-first programming; · fixing bugs before adding features; · source code version tracking software; · keeping a list of bugs and planned features instead of not keeping one; · prioritizing planned features instead of not prioritizing them; · merciless refactoring to keep the design simple; · DRY, as a criterion for what "simple" means; · "YAGNI" (not writing code to provide functionality that I'm not implementing right now); · a sustainable pace (no death marches); · exploratory "spikes" to explore unknown features; · taking regular breaks; · informal usability tests with prototypes; · standup meetings; · frequent releases; · quiet working conditions; and · retrospectives. I'd add, though these usually go without saying these days: · high-level languages; · interactive development environments, as opposed to the batch-mode approach where you submit a batch job and get back your program output an hour or a week later; · enough testing hardware that you never have to wait for a testing machine to become available in order to get your work done; · using available software libraries instead of not using them. I'm pretty confident that each and every one of these helps me build better software faster, though a few of them may vary somewhat depending on circumstances—I know a guy who can concentrate to write code better in a noisy café than in a private office, frequent releases are at best minimally useful for pacemaker firmware, and you couldn't have written qmail using existing libraries. Also, though, I'm guessing that the old codebases you're looking at with simple spreadsheets for bug lists practiced "working software over comprehensive documentation", "customer collaboration over contract negotiation", "responding to change over following a plan", and especially "individuals and interactions over processes and tools". And those are the core aspects of agile development (though not the Fake Agile we so often see). Some of these are things earlier generations of programmers could only rarely do. If you're working at a company that values processes and tools over individuals and interactions, there's not that much you can do to fix that if you couldn't start your own company; https://news.ycombinator.com/item?id=28670326 https://news.ycombinator.com/item?id=28670326 suggests one reason this is so widespread. Similarly for fixing bugs before adding features, using an interactive computer, having adequate testing hardware, and having quiet working conditions. Source control systems, automated builds, and automated test suites provided substantial benefits to teams that adopted them, but many didn't. That doesn't mean they weren't valuable at the time, just that many people did without. By contrast, I'm less convinced of the value of private offices, written spec documents, schedules, dedicated low-paid testers, scrum masters, planning poker, splitting and merging product backlog items, quantitative task estimation, and even coding interviews.

aprdm 5y ago
Great post. Totally agreed.