“Kids today”: Is programming quality going up or going down?

Not only am I as old as dirt, I started programming professionally when I was 16. So this may just be me being crotchety. But I perceive that the average quality of the code in today’s software projects is going down.

That doesn’t mean that software projects today don’t have vastly more scope and power than they did in the 1980s: they do. I’m just saying that when I engage with clients nowadays, I brace myself to see “FORTRAN 77 written in X“: huge monolithic functions with essentially-global variables, deeply embedded loops, etc. Often, X is a tag-based Web language (PHP, CF, ASP, etc.) but I’m not talking about “tag soup” per se. It’s not the particulars of markup and code that bother me, although I do think:

  • Tag-based Web languages facilitate imperative, drop-through programming
  • Tag-based Web languages are now a common early step on the “path to professional programming”
  • Therefore, tag-based Web languages aren’t blameless

Although X is often tag-based, I perceive an increase in FORTRAN 77 written in the more mainstream object-oriented languages such as C# and Java. (P.S. Please note that I’m picking on FORTRAN 77; I’m aware that Fortran (no caps!) has evolved into a powerful modern language.)

What do you think: am I just being crotchety or are “kids today” increasing the probability of experiencing really poor code? Take my self-selected, totally unscientific poll:

Update: Guillaume Theorot makes the very fair point that kids “back in the day” probably produced crap, too. I know I did. And coding has always been a young person’s job (while those who stay in SD tend to move into management). I would guess that the median age of a person whose job is writing code is 30 or less. So there’s a lot of code out there written by people who are still in the first half-dozen years of their professional career. So maybe the phenomenon is just that I had the good fortune to have long periods of my career where I was dealing with people who were significantly more experienced. Hmmm… depressingly logical.

Update 2: Implicit assumption — FORTRAN 77 in X is not easier / faster to produce than modular code. It may seem to be for the first 100 lines, but these 1,000-line monoliths are inevitably fragile as heck and development has ground to a standstill.

Hiring Freelance Flash Programmer…

I have a job that is probably about 120 hours total work for a good Flash programmer. By that, I mean I estimate that you could probably do it in about 30 hours, but if you can deliver in 120, everyone is happy.

The only caveat is that you need to be able to write ActionScript that’s not an offense to the profession of programming. I don’t want to see scaling and positioning with magic numbers:

 	var FramePointDistance = ((Number(frame_Point[2])-Number(frame_Point[0])) + 15)/4; 	_root.main.frameMC._xscale = Math.floor((currentFramedistant/146)*100); 	_root.main.frameMC._yscale = Math.floor((currentFramedistant/146)*100); 	 	_root.main.frameMC._x = -(210 - (210 - _root.main.frameMC._width)/2) ; 	//showError(_root.main.frameMC._width +":"+currentFramedistant); 	//_root.main.frameMC._x = -(140 + main.frameMC.pic._width/4) ;_root.main.frameMC._x 	//_root.main.frameMC._y = -(130 + Math.floor(main.frameMC.pic._height/1.5)) ;// 	_root.main.frameMC._y = -(127 + Math.floor(Number(frame_Point[1]))) ; 	 

Drop me a line with salary requirement and availability at lobrien@knowing.net

Wow, are program managers really that conservative?

I know that these little Zoho polls I’m running are totally unscientific, but they are interesting. Only thirteen people have voted on the question “Are corporate SD managers too risk averse or too eager?” but every vote has been “too risk averse.”

I’m very surprised by that, because back when I actually did real surveys (at Software Development and Computer Language magazines), managerial eagerness to embrace the latest shiny new toy came across as a real problem. That it’s not seen that way by the first baker’s dozen of self-selecting developers who happen to read my blog … well, I just don’t know how to take it.

Are corporate program managers too risk-averse?

I’ve been pondering this series of polls I’ve been running and wrote the following paragraph:

Standing in opposition for this need for high productivity is risk: risk of major delay, risk of a show-stopping technical incompatibility, risk of embracing a tool or technique that is reaching the end of its evolution. These types of risks can have huge costs, and it’s very reasonable for project managers to decide to be conservative, especially when it comes to critical infrastructure components.

But then I was stuck. In the next paragraph I’d like to be a little more prescriptive. But what do corporate program managers need to hear? Do they need to hear “Hey! Don’t go chasing after yet another shiny new toy!” or do they need to hear “Go for it! You can take a little risk on the technology for a prototype or a one-off or an administrative automation tool”?

Of course, I’ll try to make both points, but which should I emphasize?

Give your answer in the following poll (which, if you’re reading in an aggregator, you probably can’t see unless you follow it to my site):

Tag Soup: <strike>Worse than Ugly</strike> Perfectly Valid

Jeff “Coding Horror” Atwood has fingered a particular sore spot for me in Web Development as Tag Soup:

“Tag soup” is his name for the spaghettiperfectly valid stuff that inevitably occurs in server-side, tag-based languages. A typically hideousperfectly valid example he shows is:

 <h1>Archive for {{ year }}</h1> {% for date in days %}   {% ifchanged %}<h3>{{ date|date:"F" }}</h3>{% endifchanged %}   <a href="http://www.codinghorror.com/blog/archives/%7B%7B%20date%7Cdate:"m/d"|lower }}/">{{ date|date:"j" }}</a> {% endfor %} 

Which blithely marries presentation (HTML), control (for loop), and domain logic (the ifchanged and link).

Tag soup is a big deal, and not just for aesthetic reasons….

I started to write a fairly extensive post explaining why it was a big deal to combine presentation, control, and logic, when I happened to remember that, while it’s out of fashion, there’s a perfectly valid architectural pattern that combines them.

The Presentation-Abstraction-Control architectural pattern stands in contrast to the more popular Model-View-Controller and related patterns. Where MVC could be said to embody the theme of “separation of concerns,” PAC could be said to have the theme “Object, know thyself!” In PAC, an object knows everything there is to know about itself: it’s data, it’s behavior, and it’s presentation/UI. If that immediately sounds unwieldy, let me reassure you that PAC emphasizes object graphs and hierarchies, so lots of presentation stuff is deferred to child objects.

For instance, the “tag soup” above might be a perfectly reasonable result of a call to a function Archive.renderChangedArticles() which, in turn, might be called from the renderArchivePage() function of the Blog object. While PAC may seem unusual for user-interfaces, it’s similar to a common way of writing a custom XML serializer (that is, you define a Node toXml(Document doc) function on all your classes and let objects write what they know and defer the rest to their children objects).

The Visitor pattern or monkey-patching are alternatives to the direct writing of such functions inside a class. But still, the idea of not separating the concerns of rendering, control, and domain logic, is essentially “PAC”-ish. You can find support for this type of approach somewherein most tag-based libraries. But, of course, it’s not about what’s possible, it’s about what is facilitated.

Do any tag-based languages or tools facilitate the PAC approach? Not that I know of. It would have to be a tool that looked “more” like an IDE (with all those tools for navigating objects and functions) than a design surface (since most rendering definitions would not be associated with the object that defines the <html> root element).

Instead, we are pained by the output of tools that facilitate the cutting-and-pasting of tags to create an enormous drop-through imperative page (I’m looking at you, Dreamweaver!)