Always Get Better

Never stop looking for ways to improve

July 14th, 2014

Like it or not your clients want mobile and if you are a developer without experience in this realm you are behind the curve.

Having been mobile-centric for the past three years of my professional life, I have heard all of the different lines of thought around toolsets and approaches for creating software targeting these devices. Moreover, I’ve lived through a lot of those toolsets and approaches, and have spent time thinking about which worked well and which ones, well… sucked.

It all boils down to this:

Build native apps using the tools and languages provided by your platform.

Yes, this is the same position I held when I wrote about this almost two years ago, but I stand by it. I’ve had a chance to play and build with the likes of Adobe Air, PhoneGap/Cordova, SenchaTouch and Xamarin, but I always end up going back to Java (Android) or Objective-C (iOS) because…

Cross-Platform Isn’t Good for Anybody

Your app is iOS only… are your installed customers complaining about it not being on Android? No! Why would they care?

When talking about a new project one of the first things to come up is the idea of using X tool so we can build to a lot of platforms after writing the code once. I guess the thinking behind this is somewhere along the lines of “if we make our product available to more people, then it follows that more people will obtain it and we will make more money”. I don’t buy this.

Look at it this way – you’re up against a million apps. What sets you apart? How do you communicate that to all of your potential customers? Are downloads from the Windows Store equivalent to downloads from Google Play? Do they use their phones in the same way and monetize the same way? Are the demographics the same?

If everyone was the same, it would still be a bad idea to build your app around a cross-platform framework. Invariably these work in a lowest-common-denominator fashion meaning you get universal support by trading off native features. Yes, your app runs the same on all the platforms, but Android users are accustomed to navigating using their back button, which iPads don’t have. Instead of providing beautiful context-sensitive navigation using activities for Android and NavigationController hierarchies for iOS, you get uniform views.

“Universal” is a Lie

Okay, so most development kits come with a way to plug in your own native code for the device-specific goodness (better GPS, camera gestures, whatever). Now you’re writing native code anyway, and you’re on the hook to support all those platforms. So why would you want to go through the pain of hooking all that into a cross-platform tool instead of going directly to your platform in the first place.

Worse, your universal framework has bugs. I’m sure it’s great software but all software has bugs. When you hit a bug that stops you from moving forward, what are you going to do? When the underlying operating system software changes and your framework hasn’t been updated yet, are you not going to deploy until the author gets around to supporting the new requirements? When you choose a cross platform tool you are choosing someone else’s opinions and priorities and ceding control of your own product.

My recommendation is to pick a release target and excel at it. Will it be in the Apple ecosystem? If so, don’t be afraid to go all in. Learn how iPhone users are going to interact with your software and do everything you can to speak to them, please them, and turn them into paying customers. They don’t want a great Android experience, they want software they don’t even think about. They won’t patiently deal with your buggy software because you were so afraid of missing out on customers that you greedily deployed a boring app just to support some other platform. The “smaller” number of users is still a lot of users!

I get the fear factor, but the cross-platform tools are designed to make life easier for developers, not customers. The developer isn’t buying my product – I don’t care so much if he’s worried about synchronizing features in a future Android port of the app.

Speed is King

I want my app to load fast and I don’t want to wait around for it. You can’t get more performance than a well-written app build from native languages and tools. Don’t be afraid of XCode, Visual Studio and IntelliJ – embrace them and enjoy the barebones software you can build with them.

Thinking in New Paradigms

Suppose you do want to put your app on two different kinds of devices. Now you need to maintain your program logic in two programming languages, adding new features and squashing bugs in both places. That’s not really such a bad thing.

What if you have an ENORMOUS code base with hundreds of thousands of lines of code – how will you ever keep that synchronized between two development tracks? Well, you might a good candidate to actually use one of those cross-platform tools. Or you might be asking yourself if your work load is really appropriate for a mobile experience (something they won’t tell you — not every app belongs on a mobile device).

Apps don’t need to behave the same on different device formats. Every modern operating system has a different focus and enormous capability list that becomes adopted by its users – so evaluate what it is really like to use your app on each device. Especially for UI stuff – do you need backward navigation on Android when there is a hardware button for that? What buttons can you eliminate on iOS in favour of multi-touch gestures?

In the past 5 years I’ve added Java, Scala, Ruby, JavaScript (specifically, Node.js-style callbacks), Objective-C and lately Swift to the list of languages I’ve used extensively and thought deeply about. Each one has challenged me to look at programming differently and apply new practices to older thought patterns. Working withing multiple native environments is not a hindrance, it’s a huge boost to the quality of software you can create.

Streamlined Learning

When you use a cross-platform tool, you have an extra learning curve – that of the tool itself. I don’t buy into the thought that it improves your productivity, but I definitely see where it decreases your productivity. You need to be aware of bugs in your tool (as we mentioned earlier, your tool is great but it’s still software and software has bugs), you need to be aware of the capabilities of your tool including all the new features they add (which, by the way, just expose native features you should have been working with directly all along).

If you can avoid it, skip the cross-platform stuff and go right to your actual platform.

Putting it all together

As a programmer your job is not about writing code, it’s about connecting businesses with their objectives. A good technologist doesn’t get caught up in ideology over which approach they ought to take to build software – they decide which implementation detail will get them to their goal. So if a cross platform tool makes sense for your project, use it. Just be sure that you’re picking the right tool, and not the comfortable (for now) one

February 15th, 2010

Now that the rebellion against IE6 has hit mainstream, a brave new world of CSS3 and HTML5 has been opened to web professionals.

Beware Mixing Purposes
CSS is intended to define the appearance of elements, not their behaviour. Be very careful about “overloading” CSS to accomplish tasks best performed by JavaScript.

A popular example of poor CSS usage is drop-down menu lists. Some web programmers use CSS’ :hover selector to instruct the web browser to display sub-navigation when the user hovers over a list item.

ul#menu li:hover ul { display: block; }

This is much better accomplished using a touch of jQuery:

jQuery("ul#menu ul").css({display: "none"}); // For Opera
jQuery("ul#menu li").hover(function(){
jQuery(this).find('ul:first').css({visibility: "visible", display: "none"}).show(268);
},function(){
jQuery(this).find('ul:first').css({visibility: "hidden"});
});

Not only is this example less dependent on consistent web browser support for the CSS :hover selector, we’ve even thrown in a spiffy little roll-out animation.

Keep It Simple
The nth-child selector is one that stands to be abused by overzealous developers. Imagine this: change the display of every nth element as defined through an algebraic expression.

Why is this a bad thing? CSS is run in the same memory space as the general web page – that’s why it’s so fast. JavaScript tends to be isolated; meaning if you make an infinite loop in JavaScript, the web browser will eventually stop it from running. If the same thing happens in CSS, your web session is probably toast.

Separate Logic from Presentation
CSS was a leap forward because it separated presentation from structure; rather than programming font and colour elements, designers were able to explicitly control the way their web page appeared on screen. HTML was being used to serve the purpose CSS was designed to cover.

More recently, CSS has become a crutch to enable functionality better suited for JavaScript. When unsure about which to use, ask yourself: Does this solution affect only the display, or is some action happening?

November 13th, 2009

At last, remote desktop has a practical use!

If you are working on a web design and need to see how it will look on Mac, your only choice up until now has been to buy a low-end Mac. That’s an expensive proposition for occasional use. If you’re a web designer by trade you are probably already using a Mac anyway, but for the rest of us there is finally a better choice.

Head on over to BrowsrCamp – for a pittance ($3 gets you 2 days of access) you get to control a machine running OS X.

You can use VNC to connect to the server; if you don’t have or can’t install VNC, BrowsrCamp offers a web interface so you can access the machine directly from your browser.

It’s such a simple, wonderfully executed concept that should be in any programmer’s bag of tricks.

October 11th, 2009

If you’re fortunate enough to be using a dual-screen setup (I suggest that everyone should be using dual screens), check out these 45 wallpapers from the constantly amazing Six Revisions.
Birth of the Moon

October 10th, 2009
Get Yourself Out of Debt
Creative Commons License photo credit: faungg

When creating reports that are calculation-heavy, it’s tempting to create functions like ‘calculatePercent()’ or ‘calculatedMedian()’ so the correct numbers are available on demand.

Sounds good and convenient, but what happens when you have 100 different calculations to make across 50,000 data records? Each report will take 5 million passes to generate. That could take a long time especially if there are multiple reports being generated.

DRY – Don’t Repeat Yourself

Fortunately, the solution is straightforward. Rather than passing through those 50,000 records 100 times (once for each percentage needed), create an array for your values and calculate ALL of them in one shot. Then, just have calculatePercent() and calculateMedian() call from that array. Sounds simple, and it is as the pseudocode below shows:


for each record:
for each value:
valueList[value].append( record[value] )

July 12th, 2009

You can still see ghosts of the traditional “waterfall” method of software development in modern agile practices. The traditional model involved long periods of planning followed by development and extended maintenance periods – ideal for long-lived systems (I’m shuddering and thinking of COBOL apps running on mainframes).

With today’s rapidly-evolving platforms and business’ intolerance for risk, developers are called upon to deliver solutions faster on changing hardware and software. The focus has shifted toward quick development cycles and constant integration.

At the basic level, the process is the same: plan, build, deploy.

A full understanding of the traditional “waterfall” software development lifecycle (SDLC) can help any programming communicate more clearly with project managers or clients who are more inclined to understand projects in these terms.

Phase 1: Planning (Logic)

The planning phase of the SDLC involves communicating with the project’s key stakeholders in order to understand the project’s requirements. What are the goals of the project, and what are the expected costs?

At this stage there is no program code involved, nor is there discussion of any particular programming language or framework. The goal is to understand what the new software will do and why; not how.

The planning phase is also the time to assess other possible solutions that could meet the client’s recommendation. This is where most analysts fail – rather than let their project stop at this point, many organizations will endeavour to push their own solution. Try to ignore the dollar signs – if you can meet your clients needs by integrating an existing solution rather than developing something new, you will make them happier because they save money and end up with a product that is completely within their best interests.

Phase 2: Design

The design phase brings us closer to writing code, but we still haven’t opened our IDE yet. At this stage our job is to create the software on paper based upon the requirements we came up with in the previous step.

Many clients feel like they are in over their head when your design starts taking form, but you can’t let them off the hook. You need to take the time to explain your design and make sure the client is fully aware and in agreement with what you are doing. Teach them how to communicate with you; learn the terms they use so you can speak their language.

Phase 3: Implementation

When we start programming, this is the part we envisioned ourselves doing. In reality, this is the part we do the least (assuming we did our job right in phases 1 and 2). We’re talking about getting down and dirt with raw code.

Phase 4: Maintenance

This is the most expensive part of the project – keeping the software running. If you’re lucky you will be gone after phase 3 – if your successor (the maintenance programmer) is lucky you will have done a thorough job of your documentation in all of the previous phases.

Maintenance deserves special thought because it occurs over time, so it gets absorbed as an ongoing cost to the business. It can be hard to justify spending a lot up-front to develop a new system when the existing one “already works, and costs less”. Always weigh the ongoing costs of developing and supporting features for an aging system versus performance gains and optimizations possible with new software.

Sometimes it makes sense to keep existing software in operation; sometimes businesses hold onto decaying systems far too long. There will always be a point where the newer system costs more to operate than the old would have cost for the same stretch of time; however, the total cost of ownership – satisfaction, new features, bug fixes – needs to be considered, not just the cost of implementing the new system.

April 12th, 2009

Sony is interesting in a “I can’t turn my head… I must watch this grotesque traffic accident” kind of way. At one time the de facto standard for the Playstation 2 and other high quality electronics, it is now burdened with the Playstation 3 and its laughable sales performance. To be fair, the Playstation 3 is an engineering beauty and an elegantly powerful machine.

For the first time in 16 months, the Playstation 3 surpassed sales of Nintendo’s Wii console in Japan. While Sony is spinning the news as a sign that their console has finally become more popular than the Wii, the fact of the matter is gamers bought the PS3 in order to play popular new game titles available only on that platform.

Ironically it was Sega’s Yakuza 3 that drove the latest surge, hearkening back to the early console war days and highlighting the exact same issue: like the PS3, consumers didn’t really care that the Sega systems were more technically advanced than the Nintendo offerings. As it turned out, players bought one or the other because they wanted to play Super Mario Bros. or Sonic the Hedgehog.

The key takeaway? The platform is worthless unless there is great software to use with it.

Sony is in a bizarre spot: they have an excellent platform upon which developers can and want to develop mind-blowing content. Perhaps their platform is the most advanced and capable – so much so that learning to harness its full potential will take years. Rather than proactively encouraging development, however, Sony is coasting on the success it had with its PlayStation 2 offering and treating developers coldly rather than as partners. Rather than fight Sony for the “privilege” of developing for the PlayStation 3, many companies are simply focusing their efforts on other systems such as the Wii where larger install bases mean bigger returns on investment.

We’re very interested in the PlayStation 3 and sincerely hope that Sony doesn’t screw this one up with their arrogance. A sampling of their hallucinations include:

The PS3′s Blu-Ray Player Justifies the Machine’s Cost

Too bad the component costs Sony $100 per unit. Sony may be looking ahead to mega-games that require the storage capacity offered by Blu-Ray, but in the meantime they are marketing the PS3 as a top-of-the-line Blu-Ray player.

Problem: They don’t include a remote control, and they don’t have an Infrared receiver. If you want to watch movies you have to use your game controllers or an optional bluetooth remote control – forget about compatibility with your existing home entertainment system.

Sony is the Official Leader in Gaming

Sony believes that the Wii is in a different market and the XBox lifespan/failure rate is going to mean wider adoption in the future. Regardless of sales (it trails the XBox and Wii), Sony believes the PS3 makes it the “official” leader in gaming. We stress once again – hardware is worthless without software.

The Sony Doesn’t Compete with the Wii

According to Sony, the Wii is not a next-generation console because they don’t target hard-core gamers. Therefore by reducing prices on the PS2 (which Sony considers to be the actual competitor to the Wii), they will be diluting Nintendo’s ability to deprive them of PS3 sales. Because it makes sense to move the PS2 and leave the PS3 sitting on the shelf.