
Professional Software Development - iris-digital
http://mixmastamyk.bitbucket.org/pro_soft_dev/
======
dboreham
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).

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...

~~~
mixmastamyk
Yes, it does mention these things. Perhaps not early enough? The "really
happens"/disasters are towards the end of Part I, and there are few project
cartoons giving hints.

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.

~~~
p4wnc6
Why are "really happens" and "disasters" associated together? I assume by
"really happens" you mean the ways reality departs from what's in the book --
but when process varies over time, adapts to different personnel, business
circumstances, tech capabilities, etc., instead of remaining rigid, like
ironically rigid adherence to Agile despite variation in the above-mentioned
characteristics, _that_ is what leads to disaster.

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.

~~~
dboreham
Right. I'm not talking about bad outcomes in the grandparent. Far from it. I'm
more interested in the fact that project participants will for example
fabricate a fake manifestation of a process (fake[1] project plans, fake task
lists, fake design documents) for the benefit of external folks asking them to
"follow process". Meanwhile they get on with building the product "The Way we
Actually Do it[2]", successfully. This phenomenon can be confusing because
outsiders might conclude that the process led to success when in fact it was
the presence of people who knew how to build software successfully that led to
success and the perception of process was a mirage.

[1] By fake I don't mean fraudulent but rather something that has as its only
purpose to meet the needs of the process enforcement. For example a
requirements document that nobody reads after it has been written, or a design
document written before the manner in which the problem will be solved is well
understood (and is therefore never read). Project plans that somehow turn out
to have underestimated effort by 3X...

[2] TWWADI(tm)

~~~
p4wnc6
> This phenomenon can be confusing because outsiders might conclude that the
> process led to success when in fact it was the presence of people who knew
> how to build software successfully that led to success and the perception of
> process was a mirage.

See, I think this is actually intentional. The "process" itself exists to give
management a surface area of metrics they can datamine for their own political
needs, more or less independent from the actual success of the project or
team.

I liken it to creating Dutch books. With each layer of management you go up,
the pressure to create Dutch books that provide you with blame insurance and
protect your bonus -- crucially, diversified across _all_ different business
outcomes -- gets more intense, and the people who pull this off get
compensated hugely and can often make leaps into C-level executive teams.

Lower level managers might not consciously know about this, and on one hand
may actually think there's some truly redeeming reason to care about the
frivolous, irrelevant metrics (e.g. Agile burndown). But the higher up you go,
the more directly and unabashedly people openly function _honestly_ \-- they
know the metrics are bullshit; they know that you know that they know the
metrics are bullshit ... they don't care ... they are just getting on with
their own business of political games to diversify away bonus risk and arrange
for metrics-based blame stories for scapegoats.

It's not that it's confusing where the credit lies. It's that people _know_
the credit does not lie with the formalized process _at all_ but that they
need that excuse in order to politically manage how they get their share of
the credit.

Unfortunately, I think despite the OP's strong efforts to present the topic in
a useful, taxonomic way, the sad thing is that _treating formalized process
with this degree of veneration at all simply perpetuates the political system
that needs inexperienced developers to roll over and play dead to the system._

------
mixmastamyk
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.

~~~
nickbauman
The separation of design and construction into phases is a hangover from civil
engineering. It has the baked in assumption that the design phase is
relatively cheap, short and somewhat unpredictable the construction phase is
expensive, long and predictable. The root problem is the assumption that
specifications can be validated for correctness, like a blueprint for a bridge
can. Nothing could be further from the truth. This is a persistent myth in
software development.

~~~
agentultra
> The root problem is the assumption that specifications can be validated for
> correctness, like a blueprint for a bridge can.

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](https://www.youtube.com/watch?v=iCRqE59VXT0)

~~~
2muchcoffeeman
I draw pictures because I think in pictures.

I just took a short look at TLA+ and read a tutorial.

Don't think I could use it without drawing a picture.

~~~
agentultra
Drawing a picture is a perfectly valid and legitimate start. However I think
there are many problems where a picture is not sufficient and it's necessary
to have good, reliable mathematics to sketch out our designs and prove
properties of them.

A sketch is still useful the the absence of nothing else. But we don't build
bridges and skyscrapers that way so why is it good enough for our data-centres
and applications?

I don't think lives have to be on the line in order for software to be
considered harmful if not built correctly. There are plenty of problems where
having a thoroughly checked design will save you plenty of headaches and
afford you many more opportunities.

~~~
mikekchar
> However I think there are many problems where a picture is not sufficient
> and it's necessary to have good, reliable mathematics to sketch out our
> designs and prove properties of them.

It's necessary to have a formal language to describe this design. Such a
formal language needs to have one and only one interpretation. We should be
able to take a document written with that formal language and verify that it
meets our assumptions. We should also be able to verify that the final
implementation is isomorphic to the design.

Luckily such tools are ubiquitous. You can use whatever programming language
you like to specify your design. In the case where the programming language is
defined poorly, then you must also decide what build system and run time
environments you will support ahead of time.

You can document your assumptions using the same programming language. This is
made easier if you use a "test framework", but if needed you can also roll
your own. You can validate your design by running the tests against your
design. Normally it is best to break up your design into "units" that make it
more clear how to validate your assumptions. You can then add some extra
validation that the composition of "units" transitively validates your
assumptions.

You can verify that your final produce adheres to that design because there
will be a 1:1 mapping from the design to the final product (i.e. the final
product will be implemented using the same code as your design). There are
wonderful tools that will tell you the "coverage" of code used in the final
product that has been validated against the assumptions.

Finally, you can even specify your requirements using the same formal language
and verify that the design meets the requirements. Normally you do this by
validating that the "integration" of "units" meets your assumptions. This
should not be done without individually validating the assumptions on the
"units", though, because the "integration" can lead to exponentially growing
alternatives. Normally it is infeasible to validate each alternative.

Yes, this reply is tongue in cheek, but I am not ignorant of formal
specification methods. They have their place. That place is currently not in a
professional software development shop. We have better methods at the moment.
Possibly formal specifications methods will improve to the point where we can
reasonably use them, but we aren't there yet.

~~~
agentultra
> Possibly formal specifications methods will improve to the point where we
> can reasonably use them, but we aren't there yet.

I disagree. Amazon has had great success employing TLA+ in finding bugs,
testing design changes, and chasing aggressive optimizations [0].

Perhaps it is because there are myths that are still floating around regarding
formal methods that still make developers cringe when they hear mention of
them [1].

None the less I couldn't find reference to it in the book... did I miss it?

And besides... unit tests, I'm sure you are aware, aren't good enough alone.
They can only increase your confidence in an implementation but they prove
nothing.

If we want to start calling ourselves _engineers_ I think we better start
looking to how the other engineering disciplines operate. I don't think it
will be long before an insurance company comes along and finds actuaries
capable of monitoring risk in software development projects and liability
becomes a necessary concern.

[0] [http://research.microsoft.com/en-
us/um/people/lamport/tla/fo...](http://research.microsoft.com/en-
us/um/people/lamport/tla/formal-methods-amazon.pdf)

[1]
[http://www.fm4industry.org/index.php/G-HM-2](http://www.fm4industry.org/index.php/G-HM-2)

~~~
2muchcoffeeman
> I disagree. Amazon has had great success employing TLA+ in finding bugs,
> testing design changes, and chasing aggressive optimizations [0].

I googled TLA+ examples and tutorials and I am wondering how I would apply
this to an already existing application?

~~~
agentultra
I look for the critical bottlenecks in the application where the cost of
failure or mistakes is fairly high. This is where I feel I will get the most
"bang for the buck" so to speak.

You don't have to specify the entire application to get the benefit of high
level specifications. Even specifying the protocol between two communicating
channels can bring benefits.

------
DougWebb
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?

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.)

~~~
mixmastamyk
Great high-level feedback, thanks. I'll add a cost/estimates component to
Requirements.

~~~
mixmastamyk
I've added a stub section on the subject that I will expand as I learn more:
[http://mixmastamyk.bitbucket.org/pro_soft_dev/sdlc_2_req.htm...](http://mixmastamyk.bitbucket.org/pro_soft_dev/sdlc_2_req.html#cost-
estimation)

------
emptybits
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.

The "Models & Methodologies" chapters looks great. It may become my new "here,
read this!" when people ask me "what's agile?" or "how else?"

[http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html](http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html)

~~~
mixmastamyk
Thank you, I've tried to do exactly that, give new people a good overview with
not too much information at once, and encourage further study with copious
references.

------
Morendil
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:
[https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ](https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ)

Or again the Wikipedia page on the history of software engineering, which is
frightfully inadequate.
[https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK](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](http://leanpub.com/leprechauns)

~~~
agentultra
I haven't read all of it yet but it also seems to miss the vein of development
that has led to movements such as _Correct by Construction_ et al. The idea
that we should model our computations in a high-level specification and check
that those designs meet our goals and hold the invariants we press upon them.

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.

~~~
mixmastamyk
This is a beginners book, and keeping in mind we can't teach them everything
in the first "semester," do you still think this topic should be included?

~~~
agentultra
Definitely think the groundwork can be laid out without covering the entire
breadth of formal methods. Even a history lesson with Djiskstra, Lamport,
Mizra, et al can be illuminating. It's good to lay the foundation so that when
a beginner encounters a problem they have the instincts to know that they
should look up these tools in order to help them.

I found it a shame that I didn't encounter these tools only until very
recently. It's a well kept secret in academia that I think should be shared.

------
Achshar
Offtopic: How do I get that github.io type hosting for my own bitbucket
account? I didn't know it was possible.

Edit: It's as mixmastamyk says. I created a repo called
'achshar.bitbucket.org' and it works.

~~~
jgowans
You can use the Aerobatic add-on for Bitbucket

[https://www.aerobatic.com/](https://www.aerobatic.com/)

SSL, custom domains, static generator auto-builds, etc.

disclaimer: co-founder of Aerobatic

~~~
kannonboy
I'm an Atlassian engineer & heavy Aerobatic user. It's very nicely integrated
with Bitbucket, and has great support for Jekyll, Hugo, and arbitrary npm
builds. It also has some advantages over github.io like being able to deploy
multiple feature branches from the same repository to separate sites, so you
can have separate "staging" and "production" versions.

It is a paid offering, though you get two repositories free, and is very
pretty reasonably priced beyond that.

------
buckbova
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.

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.

~~~
mixmastamyk
> It also does look like a laundry list of buzzwords and techspeak.

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.

~~~
buckbova
I picked the Design section to read first. Perhaps that one isn't as detailed
as some of the others.

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.

~~~
mixmastamyk
Yes, I think you're right. Design is such a huge topic and hard to condense
into one chapter (one of the shorter). I will pull more details into it and
perhaps others, thanks.

------
namiller2
Why are you using Joy Division's Unknown Pleasures album as the cover of the
book?

~~~
mixmastamyk
It is a scientific image, I believe public domain. Happen to love music and
you will find that reading the book. The cover is the first clue. ;)

(More information is at the bottom of the intro/title page under
Acknowledgements).

~~~
justinator
I guess, but it's lacking the dyadic relationship between the image and the
music (or in your case: content).

That's what made that album cover so great.

~~~
cutie
Are you drunk? You think a data plot has an intimate relationship with music
but not software? Sounds like someone is romanticising. ;)

------
kennethjiang
Kudos to the author for tackling this huge and controversial topic.

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.

~~~
mixmastamyk
Thank you. I'm going to beef that up in the introduction, due to several
comments such as yours. May I quote you?

------
ascotan
Interesting book. I'll take some time to do a read through. A few things that
bother me though off the bat:

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.

~~~
mixmastamyk
Oh, always read "protip" on reddit with a smile. It is aimed at the young,
sounds like you're being a bit chatinho.

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?

------
nickpsecurity
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 _engineered_ 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.

[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2667&rep=rep1&type=pdf)

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](https://en.wikipedia.org/wiki/Major_Defect)

Note: Describes Fagan process with relevant links.

[http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...](http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf)

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](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...](https://www.eiffel.com/values/design-by-
contract/introduction/)

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. :)

~~~
aphextron
How often is formal correctness actually used in industry applications? Is
this common outside of high risk things like aerospace?

Thanks a lot for sharing this, by the way

~~~
nickpsecurity
It's not common. The problem is a combination of user demand, vendor
incentives, social issues, and no legal liability. User demand kept pushing
for more features, faster, and cheaper price at all cost. Quality, security,
and maintenance are the consistent costs. Vendors have been pushing broken
stuff intentionally since early days to make immediate profit on cost savings
then more as they supply patches. They also try to ship as fast as possible to
get First Mover advantage even though medium assurance methods still work with
that. They spend a little time upfront to knock out lots of debugging time.
Gabriel's Worse is Better essay and how much people hold onto C are examples
of the social aspect where something spreads like wildfire. They then justify
its failings or keep them for convenience. Lastly, the areas most prone to
high assurance have regulations, policies, or legal liabilities that encourage
its use whereas most vendors immunize themselves against liability with
EULA's. Worse, customers seeing unreliable, insecure systems everywhere are
conditioned to think that's inevitable rather than artificial and subject to
change.

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.altran.com/](http://www.altran.com/)

[http://www.adacore.com/customers](http://www.adacore.com/customers)

[http://www.esterel-technologies.com/success-stories/](http://www.esterel-
technologies.com/success-stories/)

[http://integrityglobalsecurity.com/pages/commercial.html](http://integrityglobalsecurity.com/pages/commercial.html)

[http://integrityglobalsecurity.com/pages/otherSolutions.html](http://integrityglobalsecurity.com/pages/otherSolutions.html)

[http://www8.hp.com/us/en/products/servers/integrity/nonstop/...](http://www8.hp.com/us/en/products/servers/integrity/nonstop/index.html)

[http://www.methode-b.com/wp-
content/uploads/sites/7/dl/thier...](http://www.methode-b.com/wp-
content/uploads/sites/7/dl/thierry_lecomte/Formal_methods_in_safety_critical_railway_systems.pdf)

------
mixmastamyk
Thanks all for the great discussion and feedback, I've already incorporated
much of it and will continue to improve the weaker sections.

------
ecesena
The double icon for external links to youtube|wikipedia|twitter etc. seems
superfluous and makes things harder to read.

~~~
mixmastamyk
I'll take a look at toning that down tomorrow.

