Changes between Version 1 and Version 2 of SoftwareEngineering/SoftwareIn30Days

Timestamp:

Feb 6, 2017, 5:41:41 AM (8 years ago)

Author:

Vijay Varadan

Comment:

--

SoftwareEngineering/SoftwareIn30Days

@@ -9 +9 @@
 == Review
 === Verdict: [[Image(htdocs:icons/up-down-arrow.png, inline, nolink)]] **YMMV**
+The authors state that the goal of the book is to provide an overview of agile methodology, but it only talks about Scrum. It's geared towards executives or decision makers who want more information & learn about its benefits. So, it's not particularly prescriptive or in-depth. I found it a little on the light side, but the information is well laid out with a fair number of case studies, so it doesn't get tedious.
 
 === The Good
+* If you're unfamiliar with agile, there's enough information here (including in the appendixes) to understand its benefits & what to reasonably expect both in the early stages of agile rollout as well as once it is implemented across the organization at large (see shortcomings in "The Bad" section below).
+* Can serve as a quick refresher if you haven't done agile in a while.
+* Reasonable amount of information without hand-waving.
+* Fairly quick read, took me about 6 hours.
 
 === The Bad
+* Since it's written by the creators of Scrum, there is a fair amount of bias & the downsides of Scrum or agile methods in general are not given any real treatment.
+* Waterfall is the whipping-boy & while its shortcomings are well-known, I've seen it work reasonably well in practice for core platform libraries & services - this is one weakness for agile, because the methodology doesn't allow for rumination or "simmer time" for design / architectural decisions based on which the foundation layer(s) is / are built. Foundation layers cannot keep changing; they must have firm, well-understood requirements, simply because other layers are built on top of them & any alterations to foundation layers will cause ripple effects all through the system. Yes, there are ways to mitigate some of that (e.g. via abstractions & loose coupling), but there are real world limits in terms of time & resources that dictate how much mitigation can be incorporated.
 
+=== The Ugly
+* Making waterfall methodology the whipping boy, without acknowledging that when used with shorter milestones & regular integration, it works better for building foundation layers - design & architectural decisions require "simmer time" & in the real world, there is a pretty high cost to making changes to foundation layers.