That's true but when you're running a business this type of analysis makes a lot of sense. As experienced software developers we're probably all pretty wary of the "big rewrite", knowing full well that this often doesn't end up saving time in the long run but rather eats up a ton of time without delivering any new features or functionality. This analysis likely helped make the case that going forward they could expect substantial time savings, not to mention happier customers.
In any case, great article overall, very interesting.
That's actually not true. You can see the trivial stuff it solves from the promo materials - you don't know the full extent of what's realistically possible to encode in the type system.
I had this thought yesterday writing C++ code - I was doing some re factoring and I copy pasted the same identifier twice instead of writing data to two separate buffers. The case where this mattered was not covered by unit testing because it's an edge case in a tightly coupled part - it's a major chore to test that kind of code for little gain.
My first instinct was "just put unit test there and forget about it" but on the other hand while buffer API is the same two buffers are semantically different so I could have made them two distinct types (eg. with template argument tag) and required untyped input buffer to be wrapped in a type explicitly stating data use case - this would have made the bug obvious and compiler would catch any discrepancy.
My point is there are plenty of non-obvious ways to prevent bugs trough a strong type system.
For example, static analysis returns nothing where it did something before. Not calling super.viewWillAppear() in a subclass does not raise the appropriate warning in Swift.
> Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization
It succinctly describes the "process" everywhere I've ever worked.
However, there are not any good reasons to avoid improving your process and output iteratively via feedback.
I've never heard that phrase before—is it yours? I really like it.
Google thinks its original to me so I've not accidentally stolen it unknowingly.
Mostly we just haven't been doing it as long.
> Mostly we just haven't been doing it as long.
This is a popular analogy (among non-programmers) but I have more recently been countering it like this:
It's generally predictable how long it will take to build a house, because many have been built, and they're all more or less the same. Sure they have different layouts, number of windows, etc, but essentially it's the same materials, same tools, and same methods.
Most programs written are not similar in the same way two houses are similar. They are more comparable to the way a house is different from an airport terminal, or a water treatment plant is different from a golf course.
Once you've built many different types of programs, you get a bit better at estimating, but each new type of program poses brand new challenges. A builder used to building small houses from wood is going to be pretty bad at estimating how long it will take to build a missile silo from concrete, and even after building both, will still not be able to come up with a very good estimate for the time to build a railway line between two cities.
Also keep in mind that typically, programmers don't build the same (or even similar) program more than once: unlike builders, we have copy+paste.
That's a very professional process, and it should also be an inspirational process.
Just because a lot of software development is haphazard doesn't mean that it has to be! Who cares if you use Swift or Ruby or C or Lisp, ignore the details - we should see the good, mature, "grown-up" things that other people do and copy & modify them!
Jack Ganssle (an embedded systems guru) has a great interview about being "a grown-up engineer" here: http://embedded.fm/episodes/2014/5/27/53-being-a-grownup-eng...
It applies to all software and hardware systems, not just embedded systems.
It should really be "that's an industry standard practice", but a huge amount of software development seems to be done in ways that don't have any systematic way to attempt to learn from mistakes.