The most popular programming languages are rapidly changing

Interesting post on Quartz:  The most popular programming languages are rapidly changing

While it is an interesting post, a number of questions came to mind on reading it:

  1. While StackOverflow is indeed a dominant system for developers seeking and sharing information, I wonder if its demographics is really representative of the entire software/technology industry.
  2. The dominance of JavaScript is hardly surprising, since if you want to do anything in the browser, you really have no choice (and choice is always a bad thing, right?).
  3. Is SQL a “programming language”? I never thought so. You cannot “build a system” in SQL – SQL may be a major part of a large number of systems, but you need a programming language to make use of it.
  4. NodeJS and AngularJS are not programming languages. They are frameworks for JavaScript. Making these two their own categories makes no sense, anymore than it would make sense to have separate categories for Python and Django and Tornado. It might make sense to have separate categories for server-side versus client-side Javascript, but not specific frameworks.
  5. Merging together the JavaScript, NodeJS and AngularJS would give a more clear indication of the use of Javascript – rather than showing a decline in JavaScript usage over the last three years.

Bing Maps WPF Control Beta with Surface 1.0

Microsoft surface table
Image via Wikipedia

As announced on the Microsoft Surface Blog (and elsewhere, I am sure), a Bing Maps WPF Control Beta has been released. This control targets WPF4 with functionality similar to the Bing Maps Silverlight control.

As a WPF4 control, with support for touch, it will also work in the Surface 2.0 environment. For those of us developing on the Surface 1.0 hardware, which of course runs over .NET 3.5, I wanted to see if I could make it work there.

Some time ago, Josh Blake wrote a post on how to write WPF4 applications for Surface 1.0 using his Blake.NUI library.

Using that same approach, I was able to build a simple application using the new Bing Maps Control under WPF4 on my Surface 1.0 hardware. On the downside, the app seems a little jumpy when panning, but I may be able to clean that up with some more work This is a start, though.

RE:Lean software development using Kanban

Nice post. Before I write anything critical about it, I want to make clear that I think the Kanban approach is very interesting.

I have a few thoughts though, as I always do when considering agile versus "heavy" processes for software development.

First, there seems to be a bit of confusion regarding "heavy processes" and "waterfall models". Heavy processes do not necessarily imply a waterfall approach to development. I was working 20 years ago on heavy (really heavy mil-spec projects) which were employing iterative, incremental development models with frequent releases and continuous integration, nightly builds and test-driven-development, before so-called agile approaches became popular.

My second thought is around development speed and quality. The post makes a significant claim regarding the performance improvement achievable without sacrificing quality. I would love to see real stats on this across a broad spectrum of projects. It also depends upon how you define "quality", and what level of quality is acceptable. Most applications developed today for the public (especially mobile apps and web content) have very low quality requirements, as the implications of a "glitch" are not that severe. On the other hand, banking and online payment software have significantly higher quality needs. Moving on to military, medical device, and other software upon which lives depend, definable, demonstrable quality objectives are required.

Over the years (over 25 years now – man I feel old suddenly) I have led or been involved with software projects following a large number of different processes, from no identifiable process at all, to heavy mil-spec processes, to modern agile processes.

Each approach had its own value, even the "no process" model, and each had its weaknesses. The challenge I have with many proponents of agile processes is that they promote agile as inherently superior to heavy processes (of course, heavy-process oriented folks do much the same towards agile folks).

In my experience, no model works for all situations. Much like selecting a technology or a programming language, it is important to select the right approach for the right job, without being too enamoured with any one approach. While a mil-spec approach is not appropriate for a small team in a start-up, an agile methodology is equally inappropriate for a 10 year, multi-billion dollar, life-critical military project employing hundreds to thousands of developers.

Recently (well, in the last 10 years), I have become a big fan of what I term "just enough process" (which I talked about in a previous post). Always use the right tools and processes for the right job.

Fred’s Laws – How not to write software

This begins a series of posts on Fred’s Laws – basically a set of anti-rules on how not to develop software.

Over the past twenty-odd years, I have seen a lot of software projects crash and burn. Many have been doomed from the start, while many others died slow, painful deaths after hopeful beginnings. Some have finished, and the systems are in production, without ever having realized that the project was a failure. Others should have failed, but managed to struggle through due to the heroic efforts of one or more dedicated (and usually really smart) people.

I have also seen more than a few “failed” projects that were technical successes. We built really cool software. We were on time, on budget, and had good quality. They failed in some other aspect – usually they were business failures for one reason or another.

The environments in which these projects have died have been varied as well. Some tried to make it with no process at all. Some had lots and lots and lots (and lots and lots) of process. I have not seen a great deal of correlation between process and success (well, except that the process I pick for my projects is always successful 😉 ).

When I look back on these catastrophic projects, usually I can see where things went wrong. In fact, most of the time I could see where they were going wrong while it was happening, like watching a car crash in slow motion, but was frequently powerless to avoid the impact. More often than not (in fact, I would be willing to say always), the root cause was something completely avoidable (from a technical or project perspective). Never was it because we chose Windows over Linux (or vice versa), nor because of the programming language we chose, nor because what we set out to do was technically impossible.

As I have written Fred’s Laws (well, written them in my head, none of them are actually written yet!) it occurs to me that they all seem to be straight from the department of the bloody obvious. No rocket science here. If they are this obvious, why even write them down. Well, the reason is that, despite how really obvious all of this is, I watch projects not do them all the time. Most of the time, in fact.

So, stay tuned. I am going to try to post one law per day (or so) until I run out of ideas.

BTW, as a little footnote, I have been involved in a few successful projects along the way. It just always seems to be the ones that failed (and failed spectacularly) that stick out in my memory.

The Next Big Language – WHY?

I have been doing some work lately teaching myself some of the basics of Ruby, Python and a couple of other languages. As I was working with these languages, I was suddenly hit with a question – why? Over the course of my career, I have programmed in a lot of languages (somewhere around 20 that I have actually used to do useful work, I think). I am sure many of you can say the same thing. And do you know what? They all suck in one way or another! I have seen language’s popularity come and go. I have seen arguments in person, in newsgroups, and all over the web which bordered on religious fanaticism. Even as I write this, a good discussion continues in response to The Next Big Language.

Again, I ask myself “why?”

Looking back over projects in which I have participated, led, observed, or otherwise been involved, I cannot think of one where the success of failure (or degree of success – failure is not usually absolute) of the project was due to the limitations of the programming language. Nor has the programming language been the determining factor in the cost of the project, or the quality or the maintainability of the code.

There are so many factors which are accepted to have much greater impact on the course of a project than the choice of language/technology – requirements, architecture, realistic planning and tracking, and proper resourcing to name a few – that I find the whole debate around programming languages to be somewhat meaningless in the real world (actually, I find it more annoying than meaningless).

This is not to say that I do not believe we should always be innovating and inventing new ways of doing things (including programming languages). It does mean, however, that it is highly unlikely that any of these language advancements (or The Next Big Language, whatever it is) will make a significant difference in software development in either a corporate IT or commercial product development world – at least not any time soon.