Definitely not. The Art of Software Testing wrote about "module testing" in 1979, which was revised as "unit testing" in a later revision after "unit test" was part of the popular lexicon. Perhaps that is what you are thinking of?
Beck is clear that he "rediscovered" the idea. People most certainly understood the importance of tests being isolated from each other in the 1960s. Is that, maybe, what you mean?
> you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.
It's not binary, it's a continuum.
With experience, it's possible to identify whether the new project or set of tasks is very similar to work done previously (possibly many times) or if it has substantial new territory with many unknowns.
The more similarity to past work, the higher the chance that reasonably accurate estimates can be created. More tasks in new territory increases unknowns and decreases estimate accuracy. Some people work in areas where new projects frequently are similar to previous projects, some people work in areas where that is not the case. I've worked in both.
Paying close attention to the patterns over the years and decades helps to improve the mapping of situation to estimate.
Yes, but where reliability is concerned, a continuum is a problem. You can't say with any certainty where any given thing is on the continuum, or even define its bounds.
This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.
In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).
> In other words, by the time code gets thrown over the wall to QA, it should already be fairly well vetted at least in the small.
My opinion is further than that. I tell my people, if you can't get a piece of software working correctly then you have not completed your job.
It is definitely an art and skill that takes guidance and practice to develop, just like designing and writing the code, but IMO it's also the minimum bar to being a complete dev.
Having said that, we do use qa and we do find stuff in qa, but they are typically the types of things that are exposed when linking systems and processes together.
> The only thing that consistently works: start on time, end on time, and don’t wait for late arrivals.
Agree, but that doesn't solve the problem of back to back mtgs. In some cases people have to physically move from one mtg room to another, or they need to use the restroom, etc.
Having the 5 min gap really is needed for those types of things.
> I don’t see any engagement with the centuries (maybe millennia) of thought on this subject
I used to be that person, but then someone pointed me to the Stanford Encyclopedia of Philosophy which was a real eye-opener.
Every set of arguments I read I thought "ya, exactly, that makes sense" and then I read the counters in the next few paragraphs "oh man, I hadn't thought of that, that's true also". Good stuff.
The term "unit test" has been used since the 1960's (if not earlier).
reply