REGISTER | LOGIN
Breaking News
Blog

React to the Software Shift

NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
name99
User Rank
Rookie
Re: Silver bullets (see Brooks[1])
name99   6/22/2017 4:16:28 PM
NO RATINGS
<< "This (product/tool/rain dance ritual) will finally cure the software shortage problem". Has it happened? No. >>

"Curing the software shortage problem" is a meaningless metric. What would it possibly mean? Software that writes itself? 

Let's consider an actually realistic metric: is it easier than ten years ago to write "quality" software? ("Quality" software is another problematic metric, but let's leave vague and assume it means things like reasonably performant, pleasant UI, somewhat capable, mostly bug-free, and so on.) And was it easier ten years ago than ten years before that? And so on?

And I think it's clear to any reasonable observer that the answer to the questions is yes. Modern frameworks and languages (C# or Swift, React or Apple's high level frameworks) make it ever easier to avoid the sorts of routine errors that were common in the past, provide at least some measure of automatic access to the improved hardware of today (some parts of your UI get parallelization and GPU graphics and compute acceleration for free), simplify the tast of network programming and so on. 

There isn't (and hasn't been) ONE single change responsible for all of this. But there has been a constant slow improvement of our SW technology, and to refuse to accept this is to promote an agenda rather than facing the truth. (Just like the people who insist that computers today feel as slow as they did ten years ago generally either 

- are still USING the same software and hardware as ten years ago OR 

- are using modern SW&HW and imagine [incorrectly] that they have an accurate recollection of how fast things were ten years ago.)

 

Our phones run a remarkable range of software, much of it written just by single individuals or small companies, and those apps and the phones themselves almost NEVER crash. In the 80s it was just routine that occasionally your floppy disk would be corrupted by something or other. In the 90's we could expect somewhat reliable persistent storage, but machines (the entire OS) still crashed a few times a week. In the 2000's OS crashes became rare, but app crashes still happened at a problematic rate.


But nowadays (especally on the new platforms that aren't forced to retain legacy bad ideas) our primary complaints are about UI --- bug reports consist of "this app sux because it doesn't do something the iOS or Android way" --- not "app crashes if you press the home button at the same time that it's playing a movie", the sort of thing we used to report about constantly in the past. 

perl_geek
User Rank
Author
Silver bullets (see Brooks[1])
perl_geek   6/22/2017 12:45:46 PM
NO RATINGS
While the right choice of environments and tools can make dramatic (order-of-magnitude) differences in programmer productivity, over the last 50 years, the world has been repeatedly subjected to claims that "This (product/tool/rain dance ritual) will finally cure the software shortage problem". Has it happened? No.

Frameworks (e.g. Ruby on Rails) usually trade speed for flexibility, If you want to do what it allows, in the preferred way, great. If not, don't let the handcuffs chafe. A lot of products pile the Pelion of editor complexity on the Ossa of design incoherence. If you know which cute icon to pick, you can produce the wrong idea faster. (At least that gets it killed sooner.)

Don't misunderstand. If you can identify the essence of your problem class (e.g. report writing or packet switching) and make it easy to change the variable parts, dramatic productivity is possible. Doing that usually takes an intelligently lazy individual immersed in the problem long enough to see the patterns.

[1] Brooks, Fred "The Mythical Man-Month", of course.

Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed