I like this book as a means to present the ways people describe how software is developed. However, as I read I'm itching to annotate it with notes on "what really happens". I've worked in this business for a few decades now, in various locations and various sizes of companies, including a few that are household names. I have NEVER seen software built on the ground in exactly the ways one sees documented (documented anywhere, not just in this book).<p>A couple of things I don't see mentioned (apologies if they're in there, I haven't read every word):<p>1. Process does (and should) vary tremendously depending on factors including the organization size, organization maturity, market maturity, experience level of the people involved, budget, etc. The book seems to suggest that there's a one-process-to-rule-them-all.<p>2. Often there are significant unknowns about a project : unknown technologies, unknown market needs, unknown requirements. Being able to accommodate the unknowns, which can mean not expending effort trying to know something unknowable, is important. The book I think gives an impression of quite confident smooth progress toward project completion that I personally have never observed.<p>Also: The value of Rubber Chickens is not mentioned...
Author here, writing this book was one of the hardest things I've ever done, and there is seemingly no end to the small issues I've faced (both writing and technical). Would appreciate some feedback to make it as good as it can be, AMA thanks.
In a book like this, I'd like to see cost estimation mentioned earlier than Chapter 8. I'd argue that in nearly all software development projects (particularly the ones where this sort of book applies) the cost of implementation is one of the key factors in evaluating requirements. If you put together your requirements without considering their cost, you end up with a project that's too expensive to build, and you want to know that during the Requirements Gathering phase, not later on during construction. Even Agile projects need to start out with a rough idea of what's being built and a rough idea of what it'll cost to build it. Otherwise how does the person funding the project decide whether or not to approve it?<p>Of course, as we all know providing estimates during the requirements phase is very difficult, especially if they're treated as hard commitments rather than rough ballparks. Chapter 2 mentions that getting requirements wrong is a key factor in causing software projects to fail; I'd say that the reason for that is usually because of the implementation costs of the known requirements that were estimated inaccurately or not at all, and the implementation costs of requirements that aren't discovered until later. It always comes down to cost; I think it's relatively rare for a software project to fail because a requirement turned out to be impossible to implement. (Unless it involves AI. You always have to watch for people trying to sneak in an AI requirement.)
Thanks to the author -- it does like like your labour of love and written with some personality. (That's a good thing!) Attractive layout, lots of insets/quotes/diagrams, and sources. Will read more later.<p>The "Models & Methodologies" chapters looks great. It may become my new "here, read this!" when people ask me "what's agile?" or "how else?"<p><a href="http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html" rel="nofollow">http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html</a>
I'm disappointed to see a book aimed at "professional" developers continue to spread outdated and debunked information, such as the NIST "study" adduced as evidence for the imperative necessity of "defect cost containment". See my post on the topic: <a href="https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ" rel="nofollow">https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ</a><p>Or again the Wikipedia page on the history of software engineering, which is frightfully inadequate. <a href="https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK" rel="nofollow">https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK</a><p>I'll add my voice to those that have already stated such a book shouldn't start by assuming the SDLC as a reference model: it embodies too many of those outdated assumptions. More in that vein in my own book <a href="http://leanpub.com/leprechauns" rel="nofollow">http://leanpub.com/leprechauns</a>
Offtopic: How do I get that github.io type hosting for my own bitbucket account? I didn't know it was possible.<p>Edit: It's as mixmastamyk says. I created a repo called 'achshar.bitbucket.org' and it works.
Definitely touch on a lot of topics here. And all looks well organized. It also does look like a laundry list of buzzwords and techspeak.<p>Obviously this wouldn't be used to teach anyone any particular topic in detail but to get them familiar with the general concepts/steps involved in software dev.<p>Edit:<p>The two books I read that I thought covered these ideas well were Code Complete and Code Craft. But it's been about a decade now. Perhaps they're too dated.
Kudos to the author for tackling this huge and controversial topic.<p>Read first several chapters and picked up the impression that the author doesn't put enough effort to point out how the processes/practices can (and should) be completely different depending on the circumstances. If a startup tries to use the same processes as Google or Facebook, it'll be dead in the water. If SpaceX engineers write software the same way as SnapChat does it, we will never see their rockets leaving launch pads.
Interesting book. I'll take some time to do a read through. A few things that bother me though off the bat:<p>1. Anything that uses the word 'protip' can not be taken seriously. I think this needs a law. 'The Law Of Silly Programming Memes - Anything using the word 'protip' cannot be taken seriously'<p>2. The 800px width format in the world of responsive design gives me pause. Basically this says 'I'm for mobile - screw you'. I would hope that a better format for this would be chosen in the future.
Here's some for you collection given I see some omissions. Cleanroom, always omitted (sighs), is a big one as it was doing agile-like development in 80's with code so reliable it was sometimes warrantied. Also one of first, formal methods that didn't require a mathematician to use. Fagan's Software Inspection Process came before that in the 70's. I throw in Praxis and 001 for good measure as they're <i>engineered</i> software methods with better results than Cleanroom albeit at higher cost. Leave off plenty of others too constrained for most software development but did prove out in smaller projects. The B Method & Chlipala's Certified Programming in Coq are examples if you want to Google around.<p><a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2667&rep=rep1&type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....</a><p>Note: An academic recently combined Cleanroom with Python for some nice results given how high-level Python is. I thought Haskell would be more ideal.<p><a href="https://en.wikipedia.org/wiki/Major_Defect" rel="nofollow">https://en.wikipedia.org/wiki/Major_Defect</a><p>Note: Describes Fagan process with relevant links.<p><a href="http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf" rel="nofollow">http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...</a><p>Note: Altran/Praxis Correct by Construction is a modern high-assurance method with numerous successes. Cost a 50% premium for nearly defect-free systems. SPARK Ada is GPL these days.<p><a href="http://htius.com/Articles/articles.htm" rel="nofollow">http://htius.com/Articles/articles.htm</a><p>Note: Margaret Hamilton, who helped invent software engineering on Apollo mission, deserves mention for the first tool that automated most of software process. You can spec a whole system... one company specified their whole factory haha... then it semi-automates design then automatically does code, testing, portability, requirements traces, and so on. Guarantees no interface errors, which are 80+% of software faults. Today's tools have better notations & performance but still can't do all that for general-purpose systems: always a niche.<p><a href="https://www.eiffel.com/values/design-by-contract/introduction/" rel="nofollow">https://www.eiffel.com/values/design-by-contract/introductio...</a><p>Note: Added Eiffel method to make up for fact that I have little to nothing on OOP given I don't use OOP. Meyer et al get credit for a powerful combo of language features and methodology in Eiffel platform with huge impact on software. Specifically, Design-by-Contract has so many benefits that even SPARK and Ada both added it to their languages. Just knocks out all kinds of problems plus can support automated generation of tests and such.<p>So, there's you some reading on methods of making robust software that might fit into your book or something else you do. :)