That's a very professional process.
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.
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.
There's nothing professional about choosing the wrong platform for your application and then jumping into a new proprietary language in the hope of fixing things with a rewrite.
Are you trying to imply they are Apple devices and/or becoming Apple devices? Because that's entirely opposite of what's going on at the several local hospitals (admittedly all under the same organization) near me.
We have a major effort at Hopkins going on right now to get around this. See this article more info: http://hub.jhu.edu/2015/10/19/hopkins-microsoft-patient-safe...
Many of us don't have any issues with comercial vendors.
"When you you do robotics, you want full control over the software"
And OS X gives me this.
Of course it's not, because OS X gives you shit and you invested so much in it already that you have to convince yourself that it tastes good.
"We use Macs to drive these robots, with control software that was written in Objective-C. We made the decision to rewrite this software in Swift late last year, but only after a careful survey of the bugs that had impacted our customers over the years. That survey revealed that most of these shipped bugs would have been prevented or detected early in Swift-based code."
Apparently they were able to categorize their shipped bugs and prevent those types of bugs from happening again with Swift. That's a very professional process.