A couple of things I don't see mentioned (apologies if they're in there, I haven't read every word):
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.
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.
Also: The value of Rubber Chickens is not mentioned...
There's so much to cover, I started out with the formal stuff first. It seemed like a good order, but perhaps it is a bit off-putting at the beginning of the book.
I'd see strict adherence to any sort of one-size-fits-all recipe for workflow management as a greater sign of disaster than healthy compromise, accommodation for individual working styles, and respect for the human need for autonomy and self-direction.
Watching an organization stress in vain to assert a one-size-fits-all approach, such as letter-of-the-law Agile, is unpleasant, especially once the political games set in. Even worse to be on the team and actively shunted from being able to do your job because of all the boilerplate, parochial adherence to cargo-cult process.
Also, from a practical standpoint, both the design and construction chapters are huge, so combining them doesn't seem to be a good idea. Perhaps I could add your warning though, if you don't mind me quoting you.
In my world (enterprise software), the design phase is usually the most expensive phase, as it tends to be staffed with expensive architect/designer/technical lead-level folks.
Yes and it is a pretty good principle. The last thing you want in a software project is a design which changes all the time.
We can validate specifications for correctness with automated theorem proving! The least we can do is model-checking. At least for the hard algorithms and core system interactions. We've had this ability for decades.
The problem with software development is that we get all hand-wavy about "architecture," and "design." I try not to physically groan when someone starts sketching out a box diagram. They're fancy pictures, sure, and useful at a conceptual level... but the reality is that the software will look nothing like that diagram. And there's no way to check that the diagram is even correct! Useless!
It doesn't have to be painfully slow, burdensome, and expensive to employ these tools either. Contrary to popular belief it doesn't take a team of highly trained PhD physicists to build a formal mathematics for modelling computations these days. There are plenty of open-source tools for using languages like TLA+ that work great besides! Ask Amazon -- they published a paper about it.
Watch Leslie Lamport - Who Builds a Skyscraper without Drawing Blueprints?: https://www.youtube.com/watch?v=iCRqE59VXT0
Btw, besides the .svg problems, the kindle version looks fine otherwise on my iPhone, it is not squished, if that helps any.
Edit: have linked several dense images, thanks.
A pdf of the full book I'm not sure about yet, should I be concerned about copying? I'm new to authoring.
As a proponent of Continuous Delivery, I found the part on releases a bit old-fashioned and slightly disappointing.
I can elaborate a bit more if you want, but most likely you're already familiar with the more iterative and automated approaches.
Everybody has their pet peeves, I guess.
Software is often delivered with hardware or other services which have to have releases, hence releases are still very much a thing.
software world > web software.
Yes, if you don't think the discussion in Ch. 7 is adequate.
https://news.ycombinator.com/item?id=12081603
...was meant for you. I knew you were in the thread but wrongly assumed you submitted the thread itself.
I'm violating my own principle, so I'll give an example: the book, Enterprise Rails, opens with a chapter titled, " The Tale of Twitter". Here's an excerpt:
https://dan.chak.org/enterprise-rails/preface/
> Because Twitter was the largest, most public Rails site around, its stumbles were watched carefully, and the steps Twitter took to alleviate its scalability issues were thoroughly documented online. In one instance, the database was becoming a bottleneck. In response, Twitter added a 16 GB caching layer using Memcache to allow them to scale horizontally. Still, many queries involving complex joins were too slow. In response, the Twitter team started storing denormalized versions of the data for faster access. In a another instance, Twitter found its use of DRb, a mechanism for remote method invocation (RMI), had created a fragile single point of failure. It replaced DRb with Starling, a distributed messaging queue that gave it looser coupling of message producers and consumers, and better fault tolerance.
> It is of no small significance that Twitter’s engineers chose to absolve Rails of being at fault for their problems; instead of offloading the blame to an external factor, they chose to take responsibility for their own design decisions. In fact, this was a wise choice. Twitter’s engineers knew that reimplementing the same architecture in a different language would have led to the same result of site outages and site sluggishness. But online rumor mills were abuzz with hints that Twitter was planning to dump Ruby and Rails as a platform. Twitter’s cofounder, Evan Williams, posted a tweet (shown in Figure 1 ) to assure everyone that Twitter had “no plans to abandon RoR.”
It's not that every chapter should open up with a jaunty Malcolm Gladwell-seque tale about the life of loves of professional development. But some of your assertions could be made more compelled with some real-world examples:
> As a student of computer science and programming, you’ve learned a significant portion of what you need to know as a rookie professional. The most difficult parts perhaps, but far from the “whole enchilada.”
There's nothing wrong with that statement. But there's not much to it besides filler that students have been told for their entire college education. You yourself must have a few personal examples of what the first week of work taught you that 4 years of college didn't. And/or, you may remember a few interns who, despite their college pedigree, found themselves to be completely over their heads. Just even a couple of sentences of showing how you came to learn the wisdom you now dispense goes a long way.
Anyway, sorry for the extended critique. I am obviously skipping over the part above to how damn hard it can be to find compelling stories :)
Keep in mind though I'm not a professional writer, far from it, a hack basically. It took untold suffering to get here, where "there's nothing wrong with this statement." Because believe me there were ten wrongs and ten revisions beforehand to get to this point.
That said, I do have a number of stories included in the text, unfortunately under five. I will keep a todo item to include more, but honestly I'll never be able to produce suspenseful text like the above. Maybe if it makes some money I'll be able to hire a pro co-author.
people will see 'Agile' or 'sprint' and cringe.
Try Ch. 7 - Models and Methodology, to skip to Agile.
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.)
It was a real eye opener for me- I'd been writing code in many languages since I was 10, but this was my first glimpse at "that other stuff" that takes up the majority of one's day.
All in all, I feel like it prepared me for what I would face in the real world. We had to do stakeholder interviews where the professor or a TA played the role of unforthcoming/neurotic stakeholder, were introduced to various general document types like stakeholder analysis, cost/benefit analysis, requirements overviews, etc. and the last 1/3 was pretty much applying all the interviews and data to an estimation process. We also did a greenfield project, an additional functionality project, and a system replacement project to work through the pitfalls of each.
I also think it was the first time I read The Mythical Man Month and Waltzing with Bears.
The two things, by far, that stick out about recent college grads (or really, new developers in general) are the inability to estimate and gather requirements and a complete lack of knowledge around source control.
GitHub and a lot of projects that are based around checking project source out has made a lot of Junior devs more familiar with at least the idea of source control, but very little prepares them for the flailing and hand wringing that comes with estimation.
The "Models & Methodologies" chapters looks great. It may become my new "here, read this!" when people ask me "what's agile?" or "how else?"
Or again the Wikipedia page on the history of software engineering, which is frightfully inadequate. https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK
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 http://leanpub.com/leprechauns
Instead there's Agile and the idea that we can throw together something that roughly works and iterate until our confidence is enough such that we can release it. The so-called, beta-driven-development. (Perhaps a vestigial remnant of the unix philosophy?).
I'm not arguing that formal methods should be used for every software project. I think Carmack was right to point out that if all software was written like the software at JPL we'd be decades behind where we are now. However I do think that it should be a part of the experience of becoming a programmer so that when we encounter hard problems we have the correct instincts to rely on mathematics to help us.
Do you believe the larger point (about cost of defects) is incorrect? Your g+ critique seems to take issue with the details of the study, but I missed an assertion it is wrong.
As to the wikipedia timeline, I cherry picked from it. The point being to pick the important things a student should know, not list everything possible. Seems your WP edits didn't make it through?
If someone made quantified claims about "the number of minutes of life lost to smoking one cigarette" I would refuse to take them seriously: I would argue that the health risk from smoking is more complex than that and can't be reduced to such a linear calculation.
This talk about "the cost of a defect" has the same characteristics. I don't mean the above argument by analogy to be convincing in and of itself, and I've written more extensively about my thinking e.g. here: https://plus.google.com/u/1/+LaurentBossavit/posts/8tB2RQoHQ...
But it's a large topic that quite possibly deserve a book of its own.
As for the history of software engineering, it's pretty much the same - to do it properly would entail writing a book, pretty much, and I didn't want to do it on WP unless I could do it properly.
Edit: It's as mixmastamyk says. I created a repo called 'achshar.bitbucket.org' and it works.
SSL, custom domains, static generator auto-builds, etc.
disclaimer: co-founder of Aerobatic
It is a paid offering, though you get two repositories free, and is very pretty reasonably priced beyond that.
Oh ok, it needs to be the entire url 'user.bitbucket.org'.
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.
Edit:
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.
Thanks, interesting. I've tried to define difficult terms, and it is aimed at a technical audience, but there is definitely room for improvement. If there are any readers having trouble, I'd appreciate hearing where. Will take a look myself as well.
I'm not trying to knock you here as I'm not exactly the audience for a publication of this type anyway.
It does give a good idea about what you should know/be familiar with and a bunch of link outs to other sources on the web.
(More information is at the bottom of the intro/title page under Acknowledgements).
That's what made that album cover so great.
Dame Jocelyn Bell Burnell on BBC radio's Life Scientific http://www.bbc.co.uk/programmes/b016812j
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.
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'
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.
Also thought it was recognized that narrow columns are easier to read, such as in a newspaper. It uses the well-regarded "read the docs" theme. Maybe zoom would help?
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....
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.
https://en.wikipedia.org/wiki/Major_Defect
Note: Describes Fagan process with relevant links.
http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...
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.
http://htius.com/Articles/articles.htm
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.
https://www.eiffel.com/values/design-by-contract/introductio...
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.
So, there's you some reading on methods of making robust software that might fit into your book or something else you do. :)
Thanks a lot for sharing this, by the way
Note: After a big recall, the hardware field is the one exception where they have all kinds of formal verification and testing. They're big on that stuff. Not same tools as software, though, for the most part.
Far as those using it, it helps to look at what products are available and who vendors say are their customers. Look at high-assurnace plus medium as many former customers of high-assurance do medium these days due to above reasons. Even most vendors in the niche are saying "F* it..." since demand is so low. So, you get especially high-security defense, a few in private security, some banking, aerospace, trains/railways, medical, critical industrial (esp factories or SCADA), firms protecting sensitive I.P., and some randoms. The suppliers are usually defense contractors (BAE's XTS-400, Rockwell-Collins AAMP7G); small teams in some big companies (eg IBM Caernarvon, Microsoft VerveOS); and small firms differentiating with quality & security (Altran/Praxis, Galois, Sentinel HYDRA, Secure64's SourceT).
Here's some examples. Some have marketing teams in overdrive. Just ignore it for use-cases, customers, and technical aspects. ;) Altran comes first as they focus on high quality or effectiveness for premium pay, with some high-assurance. Probably a model company for this sort of thing. AdaCore lists lots of examples which are actual customers. Esterel has a DSL with certified, code generator that has plenty uptake. INTEGRITY links show common industries & specific solutions that keep popping up on security side. NonStop is highly-assured for availability with reading materials probably having customer info. Last one is a railway showing B-method, most common in that domain, doing its job. Hope this list is helpful. I can't do much better in a hurry since the field is so scattered and with little self-reporting.
http://www.adacore.com/customers
http://www.esterel-technologies.com/success-stories/
http://integrityglobalsecurity.com/pages/commercial.html
http://integrityglobalsecurity.com/pages/otherSolutions.html
http://www8.hp.com/us/en/products/servers/integrity/nonstop/...
http://www.methode-b.com/wp-content/uploads/sites/7/dl/thier...
