I tend to be pedantic in my approach to coding C++. I like const, I declare access to data members private. A wider view is presented in The Wrong Kind of Paranoia.

I don't interpret this discussion as an argument against writing code like I do. I interpret it as a wider discussion on how important it is to look at the quality attributes you want from your architecture.

Using one example in the article, safety is a quality attribute that you want the architecture to provide and that's why you separate the code that irradiates patients from the user interface. I agree with James: programming in the small will not address this type of architectural issue.

In all, the main take away I get from James' point is that programming in the small is part of the solution but don't loose sight of the architecture. If you do, none of the const data you create will make any difference whatsoever.

I reviewed “Jim Coplien and Bob Martin Debate TDD”, to better understand Coplien’s position on Test-Driven Development (TDD) in “Why Most Unit Testing is Waste”.

In defining TDD, Martin states that it is infeasible for a software developer to call themselves professional if they do not practice TDD. He goes on to cite the laws of TDD:

1. Don’t write a line of production code unit you have written a failing unit test.
2. Do not write more of a unit test than is sufficient to fail. (Not compiling is a failure.)
3. Do not write more production code than is sufficient to pass the currently failing unit test.

In order to properly understand Martin, it is important to understand his use of “professional”. A professional is an expert. [1] Later, Martin says that he thinks it is irresponsible for a developer to ship a line of code that has not been executed with a unit test.

Essentially, expert software developers test their work using unit tests.

Coplien’s problems with TDD are two-fold.

1. The use of TDD without an architecture or framework.
2. The use of TDD without an architecture or framework destroys the GUI.

Both problems have the same root cause: a poor architecture. Coplien provides examples where a lack of domain knowledge contributes to these problems. A lack of domain knowledge has no bearing on the usefulness of TDD.

TDD can be used to drive architecture. Driving architecture is one thing. Bootstrapping it is another matter entirely.

Coplien and Martin agree: do some up-front architecture, but don’t knock yourself out. Let executing code inform future decisions.

How much up-front architecture is required?

Coplien says that a 2 million line program should have constructors and destructors in place and enforce important relationships between objects and that these relationships be supported by tests. And you should have executable code for this implementation within 30 minutes.

Coplien’s tests are not unit tests. Coplien defines a unit test as an API test. It tests a subset of the state space of the API arguments. It’s a heuristic. He suggests “Design by Contract” is a better choice.

Design by Contract (DBC) ties an implementation to business requirements. TDD obfuscates this because the emphasis on unit tests can make it difficult to connect functionality to business requirements. It's not clear that the use of TDD implies causality.

Martin’s position on DBC is that he prefers unit tests tied to production code instead of contracts embedded within the production code.

Martin implies that something being used (TDD) is better than something that is not being used (DBC). I agree. Lack of use implies low utility but so does misuse. Low utility does not mean that the ideas in DBC are invalid. Unfortunately, the DBC verse TDD discussion doesn't go very far before the session ends.

This debate provides clarity on bootstrapping an architecture. Bootstrapping is hard and the transition from exploring the problem space and defining an architecture to developing executing code involves many tradeoffs. A balance is required. Perhaps poor judgement creates an imbalance that results in the use of TDD too early.

I like the notion that assertions provide a nice coupling between the semantics of the interface and the code itself. This provides a clear advantage over a separate unit test to enforce these semantics. Employing assertions for pre-,  post-condition or invariants is a clear win. However, using assertions does not eliminate the need for unit tests. Both should be used to create advantage.

[1] See Professionalism and TDD (Reprise). TDD currently plays a significant role in professional behaviour. Experts exhibit professional behaviour.

2019-04-14: Replaced the link to autonomation as the original went dead.

The blog post “Estimates? We Don’t Need No Stinking Estimates!” was passed around my software team. It contains a reference to Frederick Brooks’ essay “The Mythical Man-Month”. As far as No Estimates is concerned, I like Mike Cohn’s view in “Estimates are Not Commitments”.

The reference to Brooks prompted me to review his essay and the wonderfully insightful wisdom contained therein. On introducing Brooks’ Law, Brooks writes:

Oversimplifying outrageously, we state Brooks’s Law: Adding manpower to a late project only makes it later.

People are often familiar with Brooks’ Law but are unaware of the other insights contained in The Mythical Man-Month.

Brooks describes an optimal schedule as one that uses as many people as there are independent tasks. He warns that one cannot obtain a workable schedule using more people or fewer months.

He tells us the man-month is a dangerous measure. It is dangerous because people and man-months are not interchangeable on most projects. It is also a poor measure of progress. Task partitioning, the cost of communication and overly optimistic estimates are important to keep in mind.

The key recommendation is to renegotiate the schedule without adding people and to do so that renegotiation needn’t happen again. This is ideal, but may not be practical because of commitments that require delivery at a specified time. For a look at what insight Brooks has to offer on schedules read Hatching a Catastrophe.

To think of Brooks’ Law in the manner oft quoted is to do a gross disservice to the wisdom within this essay. That is a point worth remembering the next time you are faced with poor effort estimates.

I've recently subscribed to Nautilus. I liken this magazine's depth to that of the Economist but with a scientific focus.

The chief advantage of Nautilus over the Economist, if you want to call this an advantage, is that Nautilus is published quarterly. This ensures that I can usually read it cover to cover before the next issue arrives.

In addition to the low frequency of publication, the articles are engaging and well written. There are some really great ideas in the articles that are conveyed with humour and wit that make the topics all the more interesting.

(I do enjoy the Economist, I just can't absorb all of the content each week. Slow reader, I guess.)