Monthly Archives: August 2011

What’s “Cross-Platform” Now?

It used to be that “cross-platform” meant making a program that could be run on Windows, Macs, and Linux PCs. To create a program that worked on all three platforms, you could write it in Java, or maybe Python or C depending on what the program needed to do. That’s not really the case anymore.

First there were smart-phones. In that case you could still fall back on Java ME for some phones, but not all. Certainly not Blackberrys or iPhones. Then came the iPad and the other tablet platforms. There is really no single language platform for all these desktops and mobile platforms.

But I still want to run versions of the same application on my iPad and my Windows and Linux desktops. And it can be done — look at the ubiquitous Evernote for example. I don’t know any details of their implementation, but I’m sure it’s a pain in the butt for them to maintain so many versions of their application across so many platforms.

But what is a small developer, like myself, to do? Learning all of the platforms well enough to write competent applications in a finite amount of time just doesn’t seem feasible.

Unless the web becomes the delivery platform. Some of the demonstrations I’ve seen using HTML 5 and CSS3 look just fantastic. Throw in PHP on the backend and JavaScript (or ClojureScript) on the front end and things look a bit brighter.

It would be a bit ironic if the proliferation of delivery platforms was the catalyst that drove development to a web platform.

Write the Manual First

Back when I was involved in designing medical devices, I had a saying to help guide the design: “Write the manual first.” This seemed to be an easier way for the teams to clearly describe what the device should do. Once everyone had a good feeling for how the system should operate, it was easier to move on to the more formal requirements management. Surprisingly, not everyone on the team was as fascinated with that as the Systems Integration team 😉

The same thing applies to software. There have been posts about working with the API of a program before the API is actually written. Makes sense to me. It’s just another approach to top-down design.

The approach has a couple of advantages. First, in terms of requirements elucidation, you get involvement from team members who have no training or interest in the formal process of requirements management. They don’t have to figure out what the final design will do based on a series of isolated requirements statements. They get a more holistic view of the product.

Second, it seems to lead to better architectural designs. If you start coding up the low-level classes based on your intuition, that often leads to attempts to fit the final design to a bunch of low-level architectural decisions that weren’t quite right to begin with.

This approach was not always taken on teams I’ve worked on, but on the occasions when it was, it has lead to simpler, more reliable designs in less time. It might work well for you too.

“Old” Programmers

Seems like I’ve been reading a lot of conversation about when you become too old to be a good programmer. I’ve even seen someone ask, with apparent sincerity, if 26 was too old. Of course anyone with any sense realizes that the answer is “Never!” As I’ve watched how my own performance has changed over the years, there have been a few obvious changes.

  • I am way less likely to chase after the “shiny new thing”. New stuff needs to have some demonstrated advantage over the pre-existing way of doing the same thing. (And, with very few exceptions, it has all been done before.)
  • My memory is way worse than it used to be. Holding all the details in my head at once can sometimes be more difficult that it used to be. As a result, I really strive for simpler code.
  • I don’t want to be a manager. Been there. Done that. Would rather code. There seems to be a stigma associated with not becoming a manager. Not sure why though.
  • More creative than I used to be. Can come up with way more ways to accomplish a task or new functions to add.
  • Better debugger. Have seen enough errors and their outcomes to be relatively quick about finding problems.
  • Much better at testing. I can usually think of many more corner cases than before and actually test that they are covered.
  • I dislike process even more than I used to, but now understand the reasons it can be required.
  • This biggest difference is that I make many fewer mistakes. I think this comes from being better able to imagine all the different ways that things can go wrong.

So, better at getting stuff done and generating quality code.