I dream of the day when not making use of contracts, static analysis and type based programming is seen as quality smell and not something that only a few are allowed to make use of.
It's not "disregarded", it's eclipsed by a need to ship often and ship a lot. There is a tendency to overstate amount of problems that come from bugs because they are painful to debug. Therefore, somewhat experienced programmers are often too defensive and suspect to paralysis by analysis (of which uber-complicated and rigid typing is a sort). Even if some advanced typing system will save a few days of debugging after refactoring down the line, it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier.
Advanced typing/static analysis is not a pinnacle of software engineering, it's a set of training wheels. Useful? Yeah. But sometimes you may need to skip them.
> ... it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier.
You hit the nail on the head!
However, I would like to mention that competition is only one very important factor.
I'd add that IT is a cost as it is a baker for a bakery, a cook for a restaurant, a mechanic for a repair shop. Do you want to be the n.1 restaurant? Then you must pay, so that your business is good food, not marketing - notice: the best restaurants don't even have good websites, as the food speaks for them. Yes, you must pay a lot to get the best cook, who will take all the time and require all the staff he wants/needs to prepare the best recipes, and so forth. We think we are in a better business just because IT is something relatively new, which not everyone fully understands, so we think that we are the best in everything we do, because we bring innovation. Sadly, we are not.
The current reality is that most companies are average or below-average with no great plans to further develop or to become the next IBM, NASA, Intel, or whatever. Most of them want to survive, some want to get a lot of money fast, and who knows, maybe in 5-10 years sell the company for 1,2,10 mln USD. As long as the mentality is driven by the idea of the acquisition, not by ambition, things won't change - the most efforts will be spent in hiding the pile of s* that employees do, trying to draw the right numbers on the right graphs. And even IBM, Nasa, Intel fail. They do. The difference lies in the ability to stand up and get on their feet again - learn from failures. They have also wasted huge amounts of money - it's documented everywhere, every time one of their projects gets shut down. However, they have a goal in their mind: to be the n.1 whatever they do.
Depends on what you mean by "n.1". The "n.1" restaurant in terms of monetary value is McDonalds. They do market (heavily). They don't pay for the best cook (not anywhere near). And they don't have the best recipes. But they are wildly successful. Conversely, michelin star restaurants go bankrupt all the time.
There's nothing wrong with aspiring to produce michelin star code. But as McDonalds shows, you can be incredibly ambitious and long-lasting with quality being at best a secondary priority.
> The "n.1" restaurant in terms of monetary value is McDonalds.
No, the No. 1 franchised chain of restaurants is McDonald's; there's a pretty big difference between the No. 1 restaurant and the No. 1 chain of restaurants.
> But they are wildly successful.
The chain has, over its lifetime, been wildly successful, a success initially fueled by a reputation for extremely high quality, consistency, and efficient service compared to the greasy-spoon diners that were the mainstay of low-cost restaurant food at the time of their initial growth; the recent history is something a bit different (they have, IIRC, recently ended a period of year-over-year drops in same-restaurant sales by, among other things, significantly cutting the number of restaurants, particularly the corporate-owned rather than franchised ones.)
> Conversely, michelin star restaurants go bankrupt all the time.
So do individual (independently owned and operated) McDonald's restaurants.
> But the goal of most companies isn't critical accolades, it's to make money.
Yeah, but McDonald's didn't make more money than other restaurants by skimping on quality, they made more money by being successful based on quality, and moving quickly with that success to branch out to other locations rather than merely saturated a single market, and by offloading much of the risk (and some of the rewards) of expansion to fee-paying franchisees, which is what differentiates them from single-location restaurants that are trying to extract maximum value from a particular local market.
Trying to generalize from this to say anything about succeeding in the software market is probably pointless, mostly resulting in very bad analogies.
McDonals is the Ford of restaurants. Automation (using procedures and equipment) to reduce cost and keep a consistent relatively high level of quality.
McDonalds has an executive chef with a high-end restaurant background.[1] He heads a team of other chefs. Their job is to design and test recipes that can reliably be implemented by following the directions.
Aside from marketing, which you mentioned, the quality McDonald's pays for is standardization.
Standardization is why chain restaurants exist at all. They give people a way to get a meal they know is going to be of a certain quality at a certain price with a sufficiently low probability of being surprised. Surprises are, on the whole, generally negative: Good restaurants are few and far between, especially at the fast food price point, and a sufficiently bad surprise can have health implications. There's a reason one of the first chains was White Castle: White implies purity and a standard of cleanliness, as opposed to the local greasy spoon cafe where the only assurance of quality is that it hasn't been shut down yet.
So McDonald's pays for processes and materials that it can blast out into a million little restaurants, all the same, secure in the knowledge that minimum-wage workers can be sufficiently skilled and motivated to carry out those processes and use those materials the right way. Doing anything better might lead to a much improved experience in some restaurants but it will reliably lead to total disaster in others, which is utterly contrary to the business model.
By that standard, McDonald's is fairly high quality.
> paralysis by analysis (of which uber-complicated and rigid typing is a sort).
How "paralysis by analysis" has anything to do with typing? And how is typing uber-complicated to begin with? This is ultra basic logic... And why exactly you you think dynamic langages are exempt of typing?
How does all of that has anything to do with a competitor shipping "buggy RoR-based systems a few months earlier"? You can do all kind of shit even in more statically checked langages if you really don't care about quality, and ship buggy products sooner too.
How is a system that prove that some aspects of your program is free of some class of defect should be considered "training wheels"? Do you also consider that compiler warnings are a bad thing for time to market, and so should be disabled? How can you gain any time from not using an automatic checker? Your brain is faster than a microprocessor to do repetitive tasks? This makes no sense. You do not abstain to put on your seat-belt just because you thing you know how to drive, nor do you disable all safety feature of whatever equipment just because you kind of think, without even the beginning of a reasoning to backup that, that you are going to do things "faster". And while the logic telling that what you are going to do is more dangerous is immediate and irrefutable. And while the studies about costs of discovery of bugs depending on the phase of dev clear.
Arguably there are some meta-programming aspects of Ruby which can let you program faster than with a language without equivalent features. But in no way we can deduce from this that "Advanced typing/static analysis" are "training wheels". This is one the the thing that is just so wrong in our industry that I sometimes just don't really know what to answer. I mean I could as well see a claim that the earth is flat and try to convince the crazy claimer that this is not the case, but I have the feeling that people making such claims are not sensible to logic to begin with.
> You do not abstain to put on your seat-belt just because you thing you know how to drive, nor do you disable all safety feature of whatever equipment just because you kind of think, without even the beginning of a reasoning to backup that, that you are going to do things "faster".
Lots of people do.
Yes, they often turn out dead, or missing limbs. But it's a fact that they do, to the point that industries have to police and punish people that don't use safety gear.
Developers have a similar mindset, just way less dangerous.
In my experience weakly typed languages are a trade-off, where you get something to run at all sooner but to run correctly only later. It all depends on the sort of product you're making whether that's worth it. When you're building something long-lived, there is no benefit to using a weakly typed language. Yes, initial coding takes less time, but since 70% of your cost is maintenance, it is dwarfed by the time spent debugging.
Good points, but mainly I was referring to the need to maintain extensive documentation purely for the satisfaction of bureaucratic review (though that point was in my head).
Example: All projects that are to be released must demonstrate that they are maintaining one of these:
I dream of the day when not making use of contracts, static analysis and type based programming is seen as quality smell and not something that only a few are allowed to make use of.