MIA: Google News Upgrades

When is Google going to upgrade Google News?

I don't mean anything too radical... I really, really don't want people clicking news articles straight through to Buzz on the assumption that this somehow substitutes for real communication. I have enough noise in my life already!

But I would like to see a way to promote/demote articles that the News software decides to feed me. I'm sick to death of seeing articles for the latest car models released. Let's leave aside the fact that the articles are hideously misclassified... Helloooo, Google! It's over 100 years since cars were bleeding edge Sci/Tech! At least a promote/demote system would allow their software to learn over time that I'm never going to read articles about cars or cricket... that "How Green is Your Valentine", apart from being a bit dated at this point in time, is definitely not climate-change news...

Then, too, it would be so nice to have a way to say to Google News, "Please never show me news from source X ever again." Certain news sites are so tediously flashy that they're not worth the bother of clicking through. I'd rather just make them vanish - at least from my view of the world.

Does this mean I would only get biased, half-arsed, partial news? Of course. But that's what any of us are seeing anyway!

Ah well, its pretty unlikely that Google are paying any attention to this anyway. ;-) My real point is about software adapting to the way I work, play, communicate and view the world. I'll elaborate in another post.

User Interface Redesigns

I love this quote by E. A. Vander Veer in "Why Does Facebook Keep Redesigning?"

typically users aren't considered at all when it comes to software redesigns. I wouldn't have believed this if I hadn't seen it in action on countless projects in several different companies! The attitude is, "We're the experts, we know what you want and need, our redesign is making it better, and it won't take more than a few minutes for you to get up to speed."

This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.¹

Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.

Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.

Like those who thought that adding autoboxing and varargs to the Java language was a value-add...

---

[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!

Software Design

"System Design, is one that as a profession we talk about less than I believe we should. It is, in many ways, the most important and most difficult thing that we engineers attempt to do. I believe that we avoid talking about it because it is hard, and seems somehow “unscientific.” There are clearly some designs that are good and others that are not. But the judgment of how good a design is often seems subjective or based on aesthetic principles rather than on the cold hard facts that we are engineers who pride ourselves on forming the basis for all that we do. I hope that this essay convinces some readers that the dichotomy between science and art or engineering and aesthetics is not clear, required, or even desirable. What we do must be grounded in fact, but it also needs to be grounded in taste. We should revel in that rather than trying to cover it up. It makes what we do more difficult, but also much more interesting."

-- Jim Waldo

I've been thinking a lot again, lately, about software design and how to teach it... and about how little there is out there to guide the design of good software architecture...

All part of my Quest After The Heart Of Design for the last 15 years. And maybe (just maybe!) I think I have a useful angle on it that might illuminate a path forward.

I'll say more as I develop the concept.

(And, BTW, Jim Waldo is, in my humble opinion, one of the preeminent thinkers on design alive, and one of the most interesting people I've had the privilege to meet.)

Death

So Jason and I were discussing death, as we sometimes do. In particular, what to have engraved¹ on our tombstones (assuming we get so lucky!)

"I told you I was ill" -- Spike Milligan

This quickly degenerated to the OO software-designer specific:

"I've been finalized..."

"I've been Garbage Collected."

"Finally, I've been taken up to the PermGen space!"

...all depends on your spiritual views, I suppose...

---

[1] I it just a coincidence that tombstones get engraved? Probably not.

Boolean Illogic

Why do Java programmers hate the boolean XOR operator?

Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)

I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)

if( check ){
    if( !user.isAnonymousUser() ) doStuff();
}else{
    if( user.isAnonymousUser() ) doStuff();
}

which I find nasty as hell to be sure is doing what it's supposed to, into

if( check ^ user.isAnonymouseUser() ) doStuff();

Much easier to understand, no?

How Do Development Managers Screw Up?

Here's a question, much on my mind:

What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?

Answers in comments (or email if you don't want to publicly reveal details) please!

By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.

New Courses Scheduled

Courses newly scheduled:

• Patterns of OO Design, 17-19 Feb in Cape Town
  
• OO Technology Overview for Managers, 22 Feb, Cape Town.

Please contact me directly if you're interested. Places are limited, especially for the Design Patterns course.

More to come soon... if you're interested, I suggest that you keep track of my course schedule page feed (the feed-link is near the top-right), or course-schedule calendar in your feed-reader.