Quote Of The Day: OOP

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

-- Joe Armstrong

Quote Of The Day: Attention Span

- Who wrote this code?
- When did he write it?
- What did he think then?

- Me
- Last week
- I have no idea

-- Royal Pingdom

Nature Keeps Coming With Better Idiots To Fight Concurrency

A friend of mine sent me a link to an article about Erlang style concurrency. Immediately MapReduce and Sawzall come to mind as smart paradigms intended to reduce (if only as a side effect) the complexity of concurrent programming to complexity of single threaded. And I almost start hoping that there'll be the next best thing since sliced bread which will make all the problems go away. But then, I look back at the code, more and more lines of which gets written every day, and chuckle. No way smart things can fix the situation, given into wrong hands (recent example: A340-600 ADAT accident).

So, what's the good that is supposed to come out of this rant? Very simple advice to make your life easier, if your IQ allows you to follow:

• Fughet the deadlocks and race conditions, they may be the least of your worries in the sanitized world of J2EE containers (sure, take this with a grain of salt, but not too much salt, OK?).
• Scope variables right. Not too wide, not too narrow. Using instance variables to hold request scope data is a recipe for thread safety violation and subsequent data loss and corruption. Reading configuration that doesn't change unless you redeploy the application within a loop is a recipe for a major performance impact.
• Maintain thought over and consistent instantiation and object life cycle patterns.

Now, if you think this is way too simple and can't comprehend why something this trivial should even be explained (and feel like questioning my IQ) - well, feel free to donate something to, say, DZ to alleviate my mental pain and suffering from working with code like this on a day to day basis. Why, you ask? Well, I guess someone does need to do the dirty work...

Quote Of The Day

From Coding Horror: Are You An Expert?:

Being an expert isn't telling other people what you know. It's understanding what questions to ask, and flexibly applying your knowledge to the specific situation at hand. Being an expert means providing sensible, highly contextual direction.

Best Practices: Totally Useless

Favorite quotation from this article:

Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off.

This is exactly what happened to me recently.

I was leading a project being executed by a team of cargo cult followers with copy'n'paste being the favorite technique. I've tried to nudge the developers gently into not doing certain things that were making my hair stand on end. Then, I was confronted with the statement saying that I'm being nitpicky, and need to make up my mind and "set expectations" (another beautiful corporatese term). Grudgingly, I put together the list, trimmed it down to a couple of dozen items, and passed it up. Lo and behold, it's been declared that they understand the futility of trimming down (because the "best practices" get lost in the process), and that they will take care of collecting "the words of wisdom".

Next thing I knew, the Holy Writ expanded to over two hundred commandments, and it was declared that the mental capacity of one can never be sufficient to hold that much knowledge.

And indeed, the behavior demonstrated by participants was alike to the way a sponge reacts when it is saturated: all extra water simply drips off, never penetrating the surface.

Well...

In this particular case, the only technique that actually worked was - vigilant activity monitoring (post commit, hence, post factum, unfortunately), combined with vigilant followup and correction enforcement (using terms of originally referenced article, "making sure you reach the unreachable"). After several months of this, the developers either finally started to comprehend what was required, or, possibly, got tired of redoing the same stuff fifty times and decided that it would be simpler for them to just follow the directions from the beginning rather than to try to be lazy and cut all corners possible.

The downside is that such an approach is bogging you down and forces to shift the attention to mundane things ("Never wrestle with a pig. You get dirty, and the pig enjoys it"). However, given the situation when "you have to work with the team that you're given" (which is often the case in enterprise, especially now that extreme cost savings are in effect), this may be the only option left.

UPDATE: Fixed typo.

One difference between enterprises

• Smart enterprises: spend efforts on creating automated tools supporting the process, so the human factor is alleviated, and the process is enforced.
• Stupid enterprises: spend efforts on creating documentation on what processes to follow, so the human factor is confused the hell out of, and more effort is needed to create documentation to explain what the original documentation had in mind, ad nauseum.

Handcuff Notes: Bigger Picture

One problem often found on Internet: juicy and linkbait-worthy subject is, unfortunately, totally useless for search. One example: a nice article on Java specifics with a title "Die, You Gravy Sucking Pig Dog!".

But I digress...

Like I said, nice article. Too bad it never mentions the concept of object life cycle management.

There are two realms: the language (which works just fine in Java and, no doubt, other modern languages), and the application code, which allows the programmers to write Fortran everywhere.

The horrors of improper life cycle management are formidable.

I've seen cases when an instance variable is used to hold the temporary result of execution inside of an object used by many threads, without any regard to transaction state (guess what happens when the load goes up).

I've seen cases where the complete set of application configuration files was being read by every spot where a configuration value was required - dozens, if not hundreds of times per request - for configuration that changes once in an EAR deployment.

And all in between.

Next time you start doing something complex, think of object life cycle and how it reflects on the object API. It'll save you a lot of grief.

Handcuff Notes: Writing Fortran In Any Language

More than once I've noticed that working with quality source code is easy and pleasant in any IDE, of which I've seen quite a few, or even without an IDE.

Likewise, working with crappy source is painful no matter what IDE is used. It just falls apart and explodes in your face, leaving scars on your brain as its shards fly by.

Once again, the realization that good software engineering is in perfect accord with Wu Wei, comes with enlightenment.

Android Disappointments: Good Bye, Locale

With great regrets, retired Locale today. Most regrettable because this is something I thought about as well, something that showed great promise, and something that can be greatly improved.

Doesn't seem that is destined to happen, though. At least not yet.

What makes projects great is transparency. Here, there is none.

Feedback, other than 915 ratings to date on Android Market, is hidden. Directions of further development are unknown. The only way to "get involved" is to send a mail (yeah, sure, let me whip out my spam filter). It is not known whether the project team is planning to make this an open source project, or make it a commercial application. It is not known and not clear whether the application is being actively developed, or maybe the team has reaped the benefits and moved on, releasing minor bugfixes once in a while.

Given the fact that the application is quirky and there is a lot of space for improvements (which I'm not even going to talk about until they put the cards on the table), I just call it quits.

This application is uncertain. Uncertainty is risk. Risk is threat.

The impact of this application on one's life can be a blessing or a curse - and curse much more often than a blessing, people usually notice things that go wrong and take what goes right for granted. Just imagine an alarm that's been missed because it fell into the "silent" zone, and you not making the once in a lifetime interview because of that.

*IF* Locale becomes a commercial application, I might think of buying it. But probably won't - you know, if the range top microwave falls and severs my SO's arm, I don't care much if if the installer had insurance to cover it.

But, if they decide to open it up... I just might be tempted enough to chip in my $0.02.

Too bad I don't have time to write it better from scratch, being busy doing other things...

Android vs. iPhone: What Part Of The Message You Don't Understand?

Reading SDK shoot-out: Android vs. iPhone vividly reminded me of a joke I've first heard in mid-nineties:

In seventies, IT managers were choosing VMS over Unix.
In eighties, IT managers were choosing Novell over Unix.
In nineties, IT managers were choosing Windows NT over Unix.

What part of the message you don't understand?

One quote from the article: "If you can't get coders on board, you're sunk."

Guess what, I don't have a Mac. Neither did three startups I've worked for. Neither did three corporations I've worked for. And neither of us (me, the startups and the corporations) have any intent to buy a Mac, despite an overwhelming desire to have one someday.

I've placed my bets.

Locale + Calendar Integration, Take 2

Carter from Locale team made a correction to the original post.

First of all, my apologies - I've had a tunnel vision attack and didn't see the calendar icon on the screenshot.

On the other hand, that might serve as a message that screenshots are insufficient, and they're not searchable. And that the documentation is an important part of your product - even if it is free. For now. And the front page of the project is still talking about Android release in the future tense.

But enough bickering, let me address the original point.

I guess I was thinking about Calendar integration for too long and didn't realize that what I implied too much in a cryptic message, so let me spell it out.

Let's see, yes, you can integrate a Calendar event into Locale. However, in order to do that, you need to:

1. Get the phone in your hands;
2. Open Locale;
3. Fiddle with it for a sufficiently long period of time in order to create a situation;
4. Go through the user interface that duplicates Calendar (I didn't look into technicalities, hope Calendar UI is a standard Android gadget);
5. Select the event;
6. Finish the situation.

That's a lot of work.

Now, what I actually meant was:

1. Start creating your event (in the Calendar);
2. Add a Calendar gadget that specifies notification preferences to your event;
3. Have Locale (or suchlike application) analyze the events in background and apply settings that are already specified in the events.
   

And that's all.

The point is, don't do the job you don't have to. Lazy design is a good design.

Note, it doesn't matter whether the event is being created via Web interface on your computer, or your phone. Don't know about you, but I hate the small keyboards on smartphones, no matter how good they are - maybe it's all cool and peachy while you still have all your life ahead of you, but well, I have better things to do than explore the limits of G1's mechanical excellence (more about that in a different post) in my not-so-spare time.

Having said all that, let me repeat once more that yes, I realize that per-event calendar gadget may not even exist yet (last time I checked, it didn't), but that can be addressed, and I'm sure it's either there already, or is coming soon.

More about lazy design - ahem... Give me one good reason why do you have to have a separate "manage" tab, whereas you can do the same thing in the same tab by simply using a long press?

But again, I'm nitpicking. All in all, Locale is a very useful application, and if the design team plays along with Google's way of doing things (release early, release often, improve evolutionarily) - I'm sure it'll keep being one of Android's crown jevels.

Good job, guys, and good luck.

Four R Mantra, now coming to Android

It used to be called The Microsoft Mantra: Four R's.

Retry,
Reboot,
Reinstall,
Repeat.

My Nokia never needed a reboot.

I was appalled when I was told by customer service to reboot my PEBL.

I wasn't even surprised when BlackBerry wanted to reboot after installing practically anything, and sometimes even by itself, for a good measure.

I guess I have nobody but myself to blame that I didn't figure out that a simple reboot would fix the problems I was having lately. But no, it didn't occur to me, I've put too much faith in the development team, and it took a call to T-Mobile customer service (hilarious call, I should say) to cure that.

All right, now that I know that Four R's is applicable to Android, my life is easier.

It's still disgusting, though. Thought they would do better than that.

Dynamics of Being Late to the Game

Isn't it funny that the first thing I've found while researching material for this article is the article on McNamara's Syndrome? Oh, and that being a relatively fresh (August 2008) meme at that?

Admit it, you're always late to the game. Unless you've invented the game and set the rules yourself. Which is pretty damn hard to do - the prerequisite is that you know very well what you're talking about, otherwise you're going to be ignored at least and ridiculed at worst.

There's been a lot of games in software engineering during our professional lifetime, so being late to the game kind of becomes a second nature - it is simply not possible to be aware of everything at the same time.

Then there's a separation between those who become jack of all trades, master of none, and those who tend to investigate one problem until they grok it and then move on to the next.

The first kind gets to become astronomical architects. They can easily talk about anything without actually realizing that they don't know what they are talking about. What makes matters worse, they're usually at the position of authority, and can present information believably enough so that it becomes difficult to penetrate the boundary of non-knowledge they distribute.

Meanwhile, the second kind is stuck in a deep niche 'cause they're busy solving the problem of the century. Which the humanity most probably doesn't even know about, and cares even less.

Being the second kind, though, gives you an advantage - while arriving late, you see all the mistakes that the present players have already done, and have the luxury of standing on the shoulders of giants, and can (provided you have enough brains to recognize it in the first place) generalize and streamline whatever's been done, cut the extra fat off (using your favorite tool, Occam's Razor, and remembering immortal Antoine de Saint-Exupery's saying - "Perfection is achieved, not when there's nothing more to add, but when there's nothing left to take away"), and achieve the perfection.

Or at least take a stab at it.

There's another take on it, too. Can't seem to find the quotation's origin now, just remember that it was in one of Ursula Le Guin's books, but my recollection of it sounds like this:

When you're young, you're weak, but all the roads are open to you, and there are endless possibilities. As you grow stronger, you can achieve more, but your choices narrow. An when you achieve the absolute power, you can do anything. But the wisdom you're acquired along the way makes you only do things you absolutely have to.

And there's the paradox. It's been expressed many years ago by Yuri Lesiuk, my lifetime guru, and it goes like this:

In order to know what you're doing, you have to know just a little. But in order to know what you have to know, you have to know everything.

And the question that started this rant? Simple, how do I make sure I don't have to repeat the architecture, design and coding for all currently available mobile platforms, major being (in no particular order, some may be omitted due to ignorance) BlackBerry, iPhone, Android, WinCE, Palm and Symbian. That's hell of a lot of overhead to have when you're trying to do something useful.

Lessons Nobody Wants To Learn: Enterprise Integration

It was a long time ago. I was young. It was my first job.

The job was to write a cross-compiler between two CAD systems.

On the receiving side, there was a minicomputer (a Soviet PDP-11 knockoff) running P-CAD.

On the sending side, there was a PC running some sort of a CAD supplied by, I believe, Sigmex - at least this is my recollection almost exactly 20 years later.

There was an interesting caveat to it.

You see, P-CAD is a PCB design tool.

And the Sigmex application complex was intended to create mechanical designs.

You can only imagine what sort of bribes and kickbacks could introduce a mechanical CAD system, woefully inadequate for designing PCBs, into an environment used exclusively for PCB design. I'm not even talking about the fact that there was plotting equipment designed to work with different paper size - about 2/3 of very expensive paper was being wasted into offcuts.

But I digress...

This is how ONE test run looked like:

1. Run the prototype, convert Sigmex output file into P-CAD input file;
2. Log off 6 (six) people working on P-CAD mini, busy as hell, trying to meet the production deadline;
3. Shut down the mini;
4. Take out the plotter adapter card;
5. Install the RS-232 interface card, connect the PC and the mini;
6. Boot up the mini;
7. Transfer the file from PC to mini;
8. Perform the test run on the file;
9. Withstand the scornful looks of the whole department which just lost about ten man-hours, as the following steps are conducted;
10. Shut down the mini;
11. Take out the RS-232 interface card;
12. Plug in the plotter adapter card;
13. Boot up the mini.

As you can imagine, it wasn't often that test runs were performed...

Long story short - painful attempts to produce the cross-compiler lingered for almost three years, with very little visible results. Eventually, I got sick of the task and needed to bury this dead horse once and for all.

This is what's been done:

The amount of work necessary to complete the task was doubled by adding another component to the list of deliverables. The component was a complete P-CAD file viewer.

It took less than a month to write it from scratch. Hundreds, if not thousands, of existing P-CAD files from the actual production environment were used to verify the correctness of the parser/visualizer implementation.

After this was done, the results of the dreaded cross-compiler were fed into the viewer. Since the purpose of the viewer was primarily to verify the input data, diagnostics were much, much better than "Error 0x2312980", and all the errors in the files produced were immediately obvious.

Turned out that the files were actually almost fine, with a few off-by-one and signed/unsigned conversion problems. It took a few more days to iron out those wrinkles.

The day was saved.

So, what it took to bring the project that was hopelessly beyond the budget and delivery date back in shape was a conscious decision to double the perceived amount of work to be done. Whereas it looks bizarre on the surface, it is actually not surprising.

The lessons that I learned back then were:

• You better have your APIs set in stone, thoroughly documented, with change control available, transparent and strictly followed;
• You must have a playground available for both your inputs and your outputs;
• If your input or output integration partner doesn't provide you with a playground, it is in your best interest to build one;
• Building an integration playground does NOT extend the project time and budget, on the contrary, it allows you to bring a runaway project back under control;
• If you are an API provider, it makes perfect sense for you to take responsibility for creating a sandbox of your own application, at your own expense. Complete with documentation, tutorials and help desk, of course. All this expense will pay for itself with the first API consumer, which will not bleed you with endless Q&A sessions;
• Massive amounts of test data help a lot when testing applications with either extensive protocols, and/or vague or incomplete or unknown requirement sets ("We don't know how to put this into words, but we'll know it when we see it").

It was many years later when I first saw the signs of enterprises having learned these lessons. Notable notions:

• PayPal Sandbox
• Google Checkout Sandbox
• Amazon Flexible Payment Service Sandbox is one of many sandboxes offered by Amazon Web Services
• Android Emulator is one of many examples of device emulators offered without charge by hardware and runtime manufacturers
  

But this is just about all.

Wikipedia Sandbox article was created on July 22 2006, when PayPal sandbox existed for a long time already, and Google Checkout sandbox was rolled out a month before. Two years later, it is still pretty sketchy.

The need to dedicate serious attention to sandboxes hasn't reached the attention of corporations yet.

It is counter-intuitive to invest additional resources into something you are not judged by completion of, therefore, sandboxes are not usually included into project plans.

Or, there is a reliance on "tried and true" methods of integration testing, consuming countless man-hours, extremely inconvenient and time and resource consuming because of a necessity of coordinating large numbers of people, departments and organizations, and extremely fragile due to the integration partner system downtime.

Or, simply lack of awareness.

There'll be some changes made.

Rudiments? Atavisms?

I've noticed an interesting fact during recent (and not so recent) refactoring sessions: junior programmers are using constructs that they couldn't possibly be taught using. Such as, huge blocks of variable declarations (the record is 152 declared variables: int i1, int i2; ... int i99; and so on), usually uninitialized.

The devastating consequence of this is that the compiler won't be able to detect branches that don't initialize the variables, and will happily use given default values and thus let you produce complete crap.

The closest historical origin of this is C, not even C++. It is highly unlikely that very junior Java programmers ever had any C exposure. The only explanation I have is that they keep stealing the code that was written somewhere in late nineties by some inexperienced C programmer trying to learn Java, and they keep doing that for years and years (actually, rather decades now) without a slightest attempt at comprehension of what it actually does, or where did it come from. Thus reaffirming again the painful experience of cargo cult programming.

Like the saying goes, you can write Fortran in any language...

But I wonder, maybe there's a different, better explanation?

Random Thoughts: Does It Have To Be That Stupid?

I just can't stop wondering why NetBeans even as of version 6.1 has to do the disk lookup (traversing possibly thousands of directories on network mounts) on such a simple operation as "Go To File", instead of caching those file names once per session and then updating the cache as necessary, like other IDEs do?

Russian Programmers

This text had been originally found in Russian, and then translated for the sake of my coworkers. For many years, it was hiding in backups until I found it again recently - and I think it hasn't lost its actuality since the time it's been translated (about 2000).

Original author is unknown. Original Russian text is lost (UPDATE: found again). If you are the author, or know the author, the chance to add the reference and give credit to the person who absolutely deserves it would be appreciated.

Here goes.

---

Any Russian programmer will spend just a couple of minutes to read someone else's code, and then will invariably jump and start shouting to himself: The hell with it! Throw it away! Rewrite it all! Then, a glimpse of a doubt will appear in his mind for a split second, and the rest of the day he will spend convincing himself that it is not that hard of a job to rewrite it all. And if approached right, it'll be piece of cake. But it will be The Right Thing, lean and mean and clean and nice. Next morning, he's adamantly convinced and is reporting to the supervisors that rewriting the code will take a day. No more than a day. All risks included, two days. As a result, he will be granted a week, and six months later it will be successfully finished. Until another Russian programmer sees it.

Meanwhile, in the four adjacent cubicles four Chinese programmers will work hard. In some unimaginable way, these programmers are managing to appear earlier in the office than their Russian colleague, they are managing to go home later, and at the same time they are managing to do three times less together than that one Russian guy. These four haven't produced any new code for a long time, they are just maintaining the code once written by an Indian programmer and then rewritten by two Russians. Bugs don't just live in this code. They have their nest in it. This nest is constantly reproducing itself, viciously using favorite Chinese technology known as "copy'n'paste" in other parts of the world. The bugs are proliferating from this code using static and passed by reference variables (because the Chinese programmers can't stand the inconvenience of not being able to change the value of the variables passed to their modules by the calling modules the Russian programmer is busy rewriting).

When coming across this module, the Russian programmer becomes speechless for a short period of time, then starts rapidly talking a mix of Chinese and Russian. He's long planning to rewrite the Chinese module, but he doesn't have time. The Chinese are responsible for critical bugs, and the management knows about it, and is harassing them constantly. The Chinese programmers keep hastily reassigning the bugs to each other, because they suspect that their attempts to fix the bugs will cause new, even more serious bugs. And they are right in their suspicion.

There's the only person in the office able to figure out how exactly the static variables get their values and in which order - the Indian programmer. But he's meditating. Therefore, when the Chinese Gang Of Four is laid off... Why them? Who else?!?!? Russian guy hasn't finished rewriting yet, and the Indian - the company's main asset - rarely pays any attention whatsoever to the project, but when he does, everybody is suddenly reminded that there's no one else who gets the architecture. So, when Chinese are let go, the code has two possible fates. One, Russian gets it and rewrites it. Two, Canadian gets it.

The Canadian is another thing altogether. Without a slightest hesitation, he will rush forward to fix the cruelest and nastiest Chinese made bug. The Chinese reported it fixed four times (each of them once), but every time it was back, even more intimidating, like Schwarzenegger. So, the Canadian will do what Chinese have not dared to do for the last three years. He will use the debugger to find out where exactly the static variable will become -1 instead of correct 0, and with steady hand, will introduce another static variable next to it, with the correct value. The bug will be defeated.

But the price of the victory will be high.

Everything, including the code that the Russian has just finished rewriting, will cease to work. The Russian will be dumbfounded for a couple of days, after which he will announce that of course, the design was wrong from the very beginning, and everything has to be rewritten. It will take a week. No more than a week. The Canadian will valiantly move to fix the bugs, but everything will become ever worse, though who would have thought... The commotion will kick the Indian out of meditation, and he will offer a brilliant solution - to branch the code. There will be two branches - one with The Bug, but working, and another, without The Bug, but not working either. The Russian, upon hearing of such decision, will break his slide rule in half and call his wife names after he gets home, but will say nothing to the management.

Fortunately, none of it will matter at all, because the product is selling anyway. Therefore the management is generally happy and is constantly reminding the employees that they were selected as creme de la creme. And that they have firmly established their ability to release the product by being able to release it. Once in a long while.