"Great minds discuss ideas; average minds discuss events; small minds discuss people." - Eleanor Roosevelt
Warning this is an Opinion Piece.
In a conversation this week the quote Insanity is doing everything the same way and expecting a different outcome. Or some variant of that. Attributed to Einstein. As if attributing it to Einstein makes it somehow more credible, than attributing it to Dagwood Bumstead.
Why is this Seemingly Trival Point Important
We toss around platitudes, quotes, and similar phrases in the weak and useless attempt to establish credibility of an idea by referencing some other work. Like quoting a 34 year old software report from NATO, when only mainframes and FORTRAN 77 were used, to show the software crisis and try to convince people it's the same today. Or use un-vetted, un-reviewed, charts and graphs from an opinion piece in popular techncial magazine as the basis of statistical analysis of self-selected data
Is it world shaking news? No. Is the balanced of the universe disrupted? Hardly.
But is shows a lack of mental discipline that leaks into the next level of thought process. It's always the little things that count, get those right and the big things follow. That is a quote from somewhere. But it also shows laziness of thought, use of platitudes in place of the hard work to solve nearly intractable problems, and all around disdain for working on those hard problems. It's a sign of our modern world - look for the fun stuff, the easy stuff, and the stuff we don't really want to be held accountable for if it goes wrong
I will use the Edwin Land quote though, that is properly attributed to him
Don't undertake a project unless it is manifestly important and nearly impossible.
That doesn't sound like much fun, let's work on small, simple, and easy projects and tell everyone how those successful processes we developed can be scaled to the manifestly important and nearly impossible ones.
Gentlemen, we have run out of money; now we have to think - Winston Churchill
The role of estimating in project and product development is many fold...
In both cases the future cost and future monetized value are probabilistic numbers.
With both these numbers and their Probability Distribution Function, decisions can be made about options - choices that can be made to influence the probability of project or product success.
Without this information, the microeconomics of writing software for money is not possible and the foundation of business processes abandoned.
In order to make these estimates of cost, schedule, and the technical performance of the project or product, some model is needed and the underlying uncertainty of the elements of the model. These uncertainties come in two forms
To suggest decisions can be made without knowing this future information violates the principles of microeconomics of business
It is the mark of an educated mind to rest satisfied with the degree of precision which the nature of the subject admits and not to seek exactness where only an approximation is possible —Aristotle (384 B.C - 322 B.C.)
When we hear someone say estimates are guesses, When we estimate we act as if we believe the plan will not change, or similar uninformed nonsense, think of Aristotle. Without the understanding, from education, experience, and skill to realize that all project variables are random variables and vary naturally and vary from external events.
As such in order to determine the future impacts from decisions that involve cost, schedule, and performance, we need to estimate that impact of those random processes on the outcome of our decision.
This is the basis of all decision making in the presence of uncertainty. It's been claimed decisions can be made without estimates, but until someone comes up with the way to make decisions without estimating those impacts, statistical estimating is the way.
We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense — Sir Hermann Bondi
So when we hear a suggested approach to solving any problem, what are the units of measure of the discussion elements, the inputs to that discussion, and the outcomes?
Micro-economics is defined as
A branch of economics that studies the behavior of individuals and small impacting players in making decisions on the allocation of limited resources. Typically, it applies to markets where goods or services are bought and sold.
Certainly in the software development business, goods are bought and sold. Software is developed in exchange for money. The resulting product is then put to work to generate some monetized value for the buyer. The value exchanged for the cost of that value is usually assessed as the Return on Investment
ROI = (Value - Cost of the Value) / Cost of the Value
Let's start with some basic concepts of writing software for money. I'd suggest these are immutable concepts in a for proft business world. The book on the left is a ggod start, but there are other materials about the economics of software development. The one that comes to mind is Software Engineering Economics, Barry Boehm, Prentice Hall. While some has suggested this book is dated and no longer applicable to our modern software development paradigm, that could only be true if our modern paradigm is not subject to the principles of micro-economics. And that is unlikely, so let's proceed with applying the principles of micro-economics to the problem at hand. That problem is
How can we know the cost, schedule, and performance of a software product with sufficient confidence into order to make business (micro-economic) decisions about how to manage the limited resources of the project?
Those resources are of course the variables we are trying to determine. Cost, Schedule, and Performance. Each of which contains resources. Cost in software development is primarily driven by staff. Schedule is driven by the efficacy of that staff's ability to write code. And the performance of the resulting outcomes are driven by the skills and experience of the staff, who is consuming the funds (cost) provided to the project.
So if we look at the basics of the economics of writing software for money, we'll see some simple principles.
If it's a product development effort, someone in the marketing and sales department has a planned release date. This date and the projected revenue from that release is in the sales plan. These are random numbers of course - so I won't repeat that, but all numbers in business are random numnbers until they get entered into the General Ledger.
If it's a service effort, the customer has engaged the firm to perform some work in writing software, doing consulting around that software, integrating existing software or some combination of these and other software related services. Managing the Professional Services Firm, was mandatory reading along wioth other internal company written books when I worked for a large Professional Services (PS) firm. With our small firm now, we still refer to that book.
“Ignorance more frequently begets confidence than does knowledge: it is those who know little, not those who know much, who so positively assert that this or that problem will never be solved by science.”
Along with those assertions (with no evidence) that this or that will not be solved, it is the assertion that I have a solutiuon for your complex problem that is simple and straightforward and usually involves NOT doing something that is being performed improperly, which I'll label as a dysfunction and ignore the search for the root cause.
For every complex problem there is an answer that is clear, simple, and wrong. H. L. Mencken
“If a man gives no thought about what is distant, he will find sorrow near at hand.”
When you hear that we can't make estimates, we don't need to make estimates, we don't want to make estimates, because somehow, some way, they are the smell of dysfunction. Think of this quote.
If we don't now what the cost of our work will be in the end, when that work will be complete, what will be produced from that work — and most importantly of that work will actually produce what those paying us to do the work need to do their work — then we're likely going to come to grief.
Again and again and again – what are the facts? Shun wishful thinking, ignore divine revelation, forget what ‘the stars foretell’, avoid opinion, care not what the neighbors think, never mind the unguessable ‘verdict of history’ – what are the facts, and to how many decimal places? You pilot always into an unknown future; facts are your single clue. Get the facts! ~ Robert A. Heinlein (1907-1988)
So why do we hear conjecture, unsubstantiated statements, suggestions without actionable outcomes, obvious nonsense about how to spend other peoples money?
Facts must be harder to come by than it looks.
All the exaggerations are right, if they exaggerate the right thing. (G. K. Chesterton "on Gargoyles")
When any claim is made on any topic, it needs to be backed by evidence of its applicability to the problem at hand. This means tangible evidence. No I'm exploring, or you can learn for yourself, and any general nonsense like that.
Recipes exist to get ideas, not to be followed to the letter†
The recipe for a project is described by its Capabilities. The technical and operational requirements need to support those capabilities, but defining those up front and following them to the letter restricts the creativity of the project team, just like it restricts the creativity of the chef.
† Epicurious web site comment on Vichyssoise recipe
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell
It is that difference that is needed to assess when a idea passes the smell test.
This branch of mathematics [probability] is the only one, I believe, in which good writers get results entirely erroneous - Charles Sanders Pierce
When it is said - you can't estimate the future - or we don't know total cost, think of Mr. Pierce. All things project management are probabilistic drive by the underlying statistical processes of irreducible and reducible uncertainty. Rarely, if ever, are these uncertainties Unknowable, in the mathematical sense.