On walkabout in life and technology

Reviews Should Advise

Matt “Legend” Gemmell, writing in Opinions in Journalism summarizes and continues recent internet discussions on how Tech Journalism has become too bland, impartial and hedged:

...as readers, we’re often looking for insight to help with a buying decision, rather than raw information.

As Ben Brooks sees it in Family Apple (via Hugh Sissling):

More surprising is that no one asked me which phone or computer to get — they just wanted to know which iPad to get and if they should wait for the next iPad.

Not one product review I have seen has been honest enough to say that the reader should stop wasting their time reading this \ review and just get an iPad.

If our family members know, so should the press.

Textmate 2 Tips

For those of you who, like me, have already switched to Textmate 2 alpha as a daily programmer’s editor, check out Textmate 2 Tips on tumblr. Lots of useful tips there.

Its just so nice to have Textmate being updated again. Already added the RailsCasts theme, SCSS and Marked bundles manually, and still getting used to the new File Browser.

Is America Giving Up on the Future?

Umair Haque, writing in the Harvard Business Review in Is America Giving Up on the Future? writes:

That the wealth of a nation isn't merely the sum of its tradable riches; that a thriving marketplace isn't a big box store; that industrial output matters less than human outcomes; that work that matters yields accomplishments that endure; that Goldman Sachs probably shouldn't be as profitable as Apple, because builders should earn more than shufflers; that the worth of an enduring achievement is denominated in more than mere profit; that how we feel about our lives is worth more than how enviably glamorous they look; that tomorrow matters more — not less — than today.


"You probably can't Farmville your way into the future."

Comments on the article are interesting too.

Programming Polytheism

One of the worst things a programmer can be is a monotheist, a single language and platform developer. Whether you are a corporate programming drone, or a hot-shot indie, you should be a software polytheist.

It all starts with recruiters and job ads. “Looking for a C# programmer with 5 years experience”, “Looking for a Java back-end developer who understands spring and hibernate”, “Looking for a COBOL programmer to keep our ancient accounting system running”. These are jobs requiring a single skill, for a single project for a single line of business. Don’t take them. The employer will lock you in to that skill and project, you’ll start by having fun in development and end up spending a career bored and unappreciated in maintenance. And when the product dies, so does your career.

Monotheism in programming is too easy to get stuck with. The more time you spend on a platform, the more likely you are to get the next job that requires those skills. The more time you spend in a language, the less chance of you getting work in another language or platform. Making the switch is hard, staying the course is easier.

Platforms grow, change, and rise and fall in popularity. The language and platform you are using today is most certainly not the language and platform where the hot and paying jobs will be in the future. Monotheists live and die by the current platforms, polytheists grow in skill, career, wealth and experience by moving across platforms and languages. Polytheists get the next jobs and the promotions. Monotheists become ‘too valuable’ to move as they are the only luddites who know the old platforms, their careers stagnate, and it’s cheaper to replace them with a young monotheist in the new game than to ‘retrain’ the old person in a new platform.

One of the great things about programming polytheism is the ability to use patterns and techniques from one platform in another. MVC in Javascript using Backbone.js is an excellent example of taking patterns from other platforms and applying it to scripting the browser. I finally understood delegate patterns using Cocoa and applied them in both C# and Rails projects. I finally got blocks in Ruby and applied them in Objective-C. In short, programming polytheism makes you a better programmer.

Programming polytheism also allows you to use the right tool for the right job. C++ is a rotten scripting language, yet many organizations have C++ glue code. Monotheism leads to IT departments that take three months to solve problems that take 5 line ruby scripts to fix in minutes.

So if you are a back-end C# developer, learn HTML5 and Javascript. If you are a Java programmer, learn Ruby or Python. If you only know Windows, learn UNIX. Try to learn something new at work. If you cannot, do it at home on evenings and weekends.

And then beg, nag, plead, and do whatever it takes to use these new skills on your next project. It will not only enhance your career and enjoyment of your work, but will extend it indefinitely. And your company will be more nimble and productive than ever.

I was thinking about the above when I wrote the other two articles on this day (Objective-C and iOS and Ruby on Rails). I was thinking about the differences in languages and platforms I used this year and realized that I had a ball using all of them, made better products because of my experience is a diverse set of tools and platforms, and noticed that my career has been better for it. Programming polytheism for the win.

2011 Platforms - Objective-C and iOS

Part 1 of the platforms I used in 2011 to make products. See Part 2 - Ruby on Rails.

I spent the first half of 2011 writing iOS applications in Objective-C. It’s not my first experience with Objective-C, I wrote a Mac app in 2008, and two iOS apps in 2010, so these notes are really about my entire experience with the technology.

The Cartoon Villain Behind SOPA

Kevin Fogarty, writing in Best idea of 2011: Give control of Internet content to group that sued a dead grandmother via IT World, goes after the backers of SOPA, especially the RIAA.

The anti-piracy enforcement arm of the RIAA has, for almost a decade, been so aggressive about investigating, suing and attempting to prosecute those it accused of illegally downloading movies or music that it was sued by illegal investigatory practices and invasion of privacy, for fraud, conspiracy and extortion, deceptive business practices and violation of the RICO statutes normally used to prosecute bosses of organized crime families.

And they paid Congress for SOPA.

Hiltmonism - One Version of the Truth

Its not uncommon for different software systems in a company to contain the same kinds information as others. However, it is very uncommon for this information to be the same across all systems. Often the accounting system has different information than the trading system, for example. Inventory systems often have different stock levels than sales systems.

The impact of this is that traders trade on what they know, accountants report profit on what they know, and sales happens on what they know. Since all have different information, none of them has the correct information.

These discrepancies eventually get noticed. Traders trade something they no longer have, accountants have numbers that are rejected by managers who know otherwise, and sales fail because the stock is not present. These hard to detect discrepancies get noticed, and the finger pointing, blaming, and yelling begins.

Most organizations are aware of this issue. The few that decide to do something about it usually kludge together some scripts and integration tools to move data between systems, to try to reconcile between systems, trying as best as they can to keep them in sync, or at least know when they are out of sync and use manual processes to fix it. This ‘glue’ code is usually hard to write, hard to maintain and it’s still hard to trace when data does get of alignment. Never-mind the cost of people and time to maintain these copies of the truth.

There should be only one place and one place only in your entire suite of systems to add and edit a piece of information, there should be ‘one version of the truth’. At this single control point, the information should be checked and validated, traced and controlled, and this source of the truth should feed all other systems automatically. There should be no way to edit this truth in the other systems, so that the truth remains as such.

That way, everybody in the organization is working off the same page, and each responsibility is clear.

I learned this Hiltmonism from a clothing retail chain. They were having lots of problems matching inventory with point of sales as they were on different systems. So they redesigned the point of sales system to take in the inventory data. After that, they could only sell what the inventory system said (not what the point of sales system said) and any inventory changes could only be made in one place, in the inventory system. With this ‘one version of the truth’, they all but eliminated their stock problems.

Of course, ‘one version of the truth’ is also quite risky. What if the truth is actually a bad piece of information, and this bad information flows to all other systems?

In theory this is a huge problem, in practice, not so much.

In theory, all other systems report bad information, bad decisions get made on this bad information and business fail. In practice, the bad data will either cause a later process to fail or a report to produce noticeably incorrect results, in which case the cause is easy to detect and correct, since you know where the truth comes from. In practice, you are always dealing with bad information, but if it’s the best you have, you’re making the best decisions. Usually though, a few unnoticed bad data points have no impact, so there is no real problem.

The retailer I mentioned did have invalid information in their systems, especially where ‘shrinkage’ of stock was occurring, but the impact was negligible, and very quickly picked up.

I wrote an entire Hedge Fund trading platform that relied on ‘one version of the truth’. Our error rates were the lowest in the industry by a country mile, and our support team was the smallest.

There should be one version of the truth in all systems in an organization. That way, all decisions are based on the same data, all processes predicated on the same data, all decisions use the same data and errors are easy to detect and repair, without playing the blame game.

If you have the same data in two systems, and one of them is not the source for the other, and the data in the other is not read-only, you have a problem. One version of the truth.