A Luminary Is On My Side (II)

A luminary is on my side (hey, not for the first time):

• Joel On Software (December 29th, 2005): The Perils Of JavaSchools


• Arno's Software Development Weblog (October 4th, 2004): Knowing Java But Not Having A Clue?

As A Software Developer, You Don't Live On An Island (Part II)

Yesterday I talked about the fact that as software developers, we should be prepared for change.

But of course, there is the other extreme as well. Self-taught semi-professionals missing real project experience as well as the feedback of more adept peers. Those who jump on the bandwagon of every hype, but do so in a fundamentally flawed way.

Like the guys who took the "a real man writes his own web framework"-joke for serious, and invested several man-years in a doomed attempt to create a chimera that combined web user interface components and object-relational mapping (and by "combine" I mean tight coupling, you bet) - just because they didn't like Struts or Hibernate, and quote: "Java Server Faces are still in Beta". They also didn't like the Java Collections API, so they wrote their own (interface-compatible) implementation.

Another developer was so convinced of webservices and any other technology that he could possibly apply that he suggested to compile report layouts into .NET assemblies, store those assemblies in database BLOBS and download them to the intranet(!) client using webservices (byte-arrays serialized over XML). Need to say more?

As A Software Developer, You Don't Live On An Island (Part I)

Maybe my expectations are too high, but how come that so many software developers suffer from the ostrich syndrome? They have been doing their RPG or Visual Basic or SQLWindows or <place_your_favorite_outdated_technology_here> programming for ten years or longer, but during all that time they never managed to look beyond their own nose. Now they suddenly face a migration to Java or VB.NET, or they must provide a webservice interface or the like. OOP, what's that? Unicode, what's that? XML, that looks easy, let's just do some printf()s (or whatever the RPG counterpart to printf() is ;-) ) with all these funny brackets. Oh, and when there is something new to learn, those folks of course expect their employer to send them on training for months.

I always thought this profession would mainly attract people who embrace change. Seems I was wrong.

Besides everyday project business, I try to stay in touch with the latest in technology. Readings books, magazines and weblogs, listening to podcasts, talking with colleagues who are into some new stuff, and the like.

Reading one book a month about something you haven't dealt yet (may it be a C# primer or a Linux admin tutorial or whatever) - that's the minimum I recommend to every software developer with some sense of personal responsibility.

Seven Habits Of Highly Effective Programmers

"Seven Habits of Highly Effective Programmers" is one of several excellent articles on technicat.com.

LINQ

LINQ or "Language Integrated Query" will be part of .NET 3.0 - absolutely amazing stuff. I have to admit I am still rubbing my eyes - did Anders Hejlsberg just solve the object/relational mismatch as well as making painful XML programming models like DOM or XPath obsolete? Let's wait and see...

Now I have not really been too fond of one or two C# language constructs (don't get me wrong, the features themselves are great, it's just their syntax flavor - e.g. the way the notion of delegates and events looks like), but I have always admired Hejlsberg (of Turbo Pascal, Delphi and C# fame, for those who don't know) and his achievements for our industry. And LINQ really seems to be the icing on the cake.

30 Years Of Personal Computer

Nice article about 30 Years Of Personal Computer, just one doubt: Did the Tandy-Radio Shack 80 really outsell the Apple II in the late 70s? I always assumed Apple was market leader until the introduction of the IBM PC.



By the way, we both had a TRS-80 and some Commodore CBMs side by side at school but we only used the Commodore, because to us it somehow seemed cooler.

Object Oriented Crimes

80% of software development is maintenance work. That's reality, and I don't complain about that. I also don't complain about having to dig through other people's code that is sometimes hard to understand. It's just the same as when looking at some of my own old work - the design mistakes of the past are pretty obvious today. Maybe it was just that you had to find a pragmatic solution under project schedule pressure back then - it might not be beautiful, but it worked.

But then there are also programming perversions that are simply beyond good and evil (similar to the ones posted on The Daily WTF). Let me give you two examples - coincidentally each of those came from German vendors...

Case #1:
Java AWT UI (yes, the old days...), card layout, so there is one form visible at a time and the other forms are sent to the back. Now those UI classes need to exchange data, and this was achieved by putting all data into protected static variables in the base class, so that all derived classes could access it. Beautiful, isn't it? But that's not the whole story. Those static variables weren't business objects in the common sense - they were plain stupid string arrays. One array for each business object attribute (and of course, each datatype was represented by a string), and the actual "object" was identified by the array index. You know, something like this:

protected static String[] employeeFirstName;
protected static String[] employeeLastName;
protected static String[] employeeIncome;
protected static int currentEmployee;

The memory alone still makes me shudder today...

Case #2:
Years later, this time we talk about a .NET WinForms application. Somehow the development lead had heard that it's a good idea to separate visualization from business model, so he invented two kinds of classes: UI classes and business object classes. Doesn't sound too bad? Well, first of all he kind of forgot about the third layer (data access, that's it!), and spilled his SQL statements all over his business objects. And by that I don't mean that you could read your SQL statement in clear text. No, they were created by a bizarre concatenated mechanism, which included the concept of putting some parts of the SQL code in base classes (re-use, you know), and distribute the rest over property getters within the derived classes. And this SQL code did not only cover business-relevant logic, it was also responsible for populating completely unrelated UI controls. The so called "business object" also contained information about which grid row or which tab page had been selected by the user - yeah, talking about interpretating another OO concept completely wrong. The Model-View-Controller design pattern is all about loose coupling, so that models can be applied with different views.

Uuuh, I try to repress the thought about it, but it keeps coming back...

For a developer, being able to start a project without this kind of legacy burden is a blessing. I appreciate it each time management decides to trust its own people to build up something from scratch, instead of buying in third party garbage like that.