Tag: Development
Is Microsoft Winning, or Losing, the War for Developers?
In my inbox this morning was an interesting question concerning whether Microsoft was winning, or losing the war for developers.
This used to be an easy question for me to answer, whenever someone advocated for anything other than the PC ecosystem. I would ask the person “name the killer app for platform xyz.” I would be met with stony silence, while I easily rattled off dozens of names of apps on the PC, that could be found no where else.
This is no longer even a credible line of inquiry, given the successes of the Android and Apple mobile platforms. In fact, by comparison, the relative paucity of highly recognizable titles available only on PCs (or any Microsoft platform) is quite telling.
That in itself answers the question as to whether Microsoft is winning or losing the hearts and souls of developers.
They are clearly losing – and losing badly.
Project Lifetimes
Usually when one discusses project lifetimes, it is almost always in the context of describing the time and events between when a project is conceived, when it is delivered, and all that stuff that happens between those two fenceposts.
But project delivery is just the beginning of a project’s lifetime.
By a far sight.
My longest lived project, gauged by years in production and useful life, was eighteen years (an MS-DOS based electrical estimation project that was retired in 2007). My current “dean” of active software projects, running in pretty much the same form I completed it, is an engineering design product called SAND that I developed for the Bank of America (and now actively maintained by HP) – in continuous production since 1998.
In short, software projects can have surprisingly long lifetimes.
That’s why when I hear designers and developers say that they’re doing something because it’s expedient and that they will go back later and “do it the right way”, I cringe. Because practical experience tells me we usually never get a chance to “redo something the right way” once a project gets out into the wild.
Some developers – quite wrongly – expect their responsibilities and obligations on projects to end the moment their contractual obligations free them to move on the next thing.
A great many software projects would have happier endings if developers took their responsibility and obligation in products with all the gravitas that would normally go along with birthing something that could have a potential lifetime in decades.
Most of us consider our spans of administrative control to cover only that period from one paycheck to the next.
And our software is all the worse for it.
This isn’t a paean to Work as Life – only a lament that as developers we often don’t envision that our creations will have lives that far outrun our ability to dream.
Monday Morning Quarterbacking
I spent a great deal of time with Android over the weekend – more than anyone ever should over a long, hot, holiday weekend.
By and large, working with Android is a not unpleasant experience.
It just isn’t all that great either, in some very important aspects: screen design, camera operations, and available memory.
All Android apps are constrained to a 16MB heap space for memory. This may seem like a lot, but once an app gets up and running, this memory gets fragmented – fast – so that you dont have large available chunks of contiguous memory just laying around for allocation. Throw in a few moderately sized bitmaps, and hello Mr. OutOfMemoryException. All the bitmap recycling and garbage collection in the world can’t always keep an image bound app and on its feet without its share of crashes owing to not enough memory available from the VM to load new images. In fact, the only way to have a moderately stable image intensive app is to be diligent, garbage collect liberally, and don’t be sentimental about hanging onto anything too long in memory.
The horrible state of screen / UI design tools for Android is an embarrassment. This is not particularly surprising coming from a company slanted toward engineers. I have come to love Apple’s Interface Builder all the more because of the shit you have to put up with on Android and Blackberry. Let me just say that designing screens using an XML text editor blows more than Whale. It blows Blue Whale.
Finally, one of my more vehement dislikes about Android, is the non-consistency across handsets in how images are returned back to applications from the Camera. For iPhone developers used to the very powerful UIImagePicker interface, the operation of the Android Camera Intent is a cold splash of “what the eff is this?”
Really, gentle reader, I don’t want to bore you with all the gory details about camera handling. I’ll simply point you to one of the (sadly) more widely read threads on the topic (http://code.google.com/p/android/issues/detail?id=1480, a classic) and let all the other tortured souls in Android Camera Purgatory speak for themselves.
Given all of the preceding, there is still much to be admired about Android. The fact that new releases can be put into the wild as fast as my fat little fingers can bang out and QA code, rather than the Apple “submit and pray” model, is more than a little awesome. It’s very awesome.
The metrics I get back concerning who has bought (or bought and unbought) compared to what I get from Apple’s Financial Reports is also a great plus for the platform. I’m never really sure with Apple what these numbers represent in terms of actual activity, whereas with Google Checkout I get a scary amount of transaction activity information.
I’ve said this more than a few times: I’m a platform agnostic. I live by a very hedonistic calculus with regard to where I spend my time developing mobile applications – if the platform pays, I play.
Being an aesthete about one platform or another when all I really want to do is pay my kid’s tuition and hopefully my mortgage is a total waste of time.
But it doesn’t mean that one can’t have strong likes and dislikes about the environments you’re working on. And then spending a good chunk of a Monday morning bitching about it.
There. That’s better.
Living the 80-20 Rule
For the past few weeks I’ve been living the 80-20 rule, up close and personal.
You know the 80-20 rule. 80% of the work can be done in 20% of the time, but the last 20% of the work can be a real witch to complete.
I’ve had several apps lately that I – in all honesty – slayed getting up for the most part, on time or early.
But oh that last 20%.
The part that differentiates the hobbyist from the professional. The part that allows my kids to eat and for the bank to hear from me once a month.
The part that really counts.
Strange how you can go for months and have very little friction in projects, and then hit a patch of time where everything – and I do mean everything – is an effort.
What to do during those rough patches?
Push through.
Because these rough patches are when real learning occurs. Those development lessons that stay with you so that when you see them again, you gingerly step over the land mines. Those development lessons that enable you to say to a customer “yeah, you could do that, but be warned that you will encounter a, b, and c.”
It is a trusim in writing that to be a better writer, one must constantly write. The same is doubly true in software development.
In sports, it’s analogous to practicing at the speed and intensity that you plan to play the actual game, so that your body remembers what it feels like to perform at speed, at top ability.
I read an interview over the weekend with Philip Seymour Hoffman (PSH) in the New York Times. PSH felt great acting was torturous. I understood exactly what he was saying. To be great, you can’t quit at the 80%. It’s the last 20% that is hell.
Anyone can be good. To be great, that last 20% of effort, where all the dues are paid, has to be pushed through.
This morning, I went to Einstein Bros Bagels for breakfast. When I got home, my order was correct as far as getting the right number of bagels and the right variety were concerned.
But all of the bagels were cut only to the halfway point. They may have well not sliced them at all.
Look – in the big scheme of big schemes, this was the smallest of deals.
But being half-assed in the last little detail of any transaction can ruin the entire experience.
The bagels were delicious. The carelessness of detail, however, will make me reconsider my choice of breakfast locales.
All because the last 20% of effort – hell, not even that – was tossed away.
Do what you do, the best you can, at speed, and completely.
Do that, and you will succeed.
Because most people bother only with the 80% and not with the 20%.
A Peeve That is Too Big To Keep As a Pet
Even grizzled, seasoned developers need help. Like all the time.
Stick around long enough, and you forget enough knowledge to fill several libraries.
Which brings me around to something that gets under my skin more than I care to admit.
Let’s say you’re browsing around for the solution to a programming issue you’re having. And you’re under a deadline. And the breaks aren’t going your way.
Fortuitous Day! You find a post on a message board with someone having (or who just had) the same issue you’re having. Maybe you won’t be up all night after all.
You read the problem description (yeah… that’s what I’m seeing)… and then the plea from the poor schmuck for guidance from the community (feel your pain, buddy)…
And then the inevitable happens.
“Hey Loser.”
“Read The F*#$ing Manual.”
RTFM. It’s in the documentation. Just read, stupid.
And that, my friends, is why I have not posted a question on a programming message board. Ever.
It’s not the fear of being ridiculed. I’ve been married for 23 years (rim shot).
No – it’s having to endure some idiot, who doesn’t know the answer either, try to elevate his importance (you go, l3371killa833z) by belittling others.
You find these bags everywhere. The Apple Developer boards seem to be overly represented with this particular mode of socially stunted douchiness.
Look – there are lazy developers out there, who don’t want to do the hard work of learning their craft. Who don’t put in the hours. Who pay no dues.
But by and large, these guys are in the minority.
If all you have to add to a discussion is RTFM, then may I kindly suggest you STFU.
Corporate Development and The Cowboy Coder
I’ve been fairly heavily involved in a corporate development environment for the past few weeks, on-site for a large part of that time.
This differs from my normal modus operandi, in that usually I’m doing a half-dozen different projects in various stages of completion at any given time of day, and from various venues around town.
Having to report to a set place – in this case, a cubicle – to do one thing and one thing only for a predetermined set of fixed hours was needless to say a bit of a challenge for me.
Not because of the office in which I found myself or the people that I worked with – all great, by the way – but because after twelve years of self-determination and self-direction, it is very hard to let someone else “drive” and to sit in the passenger seat.
Plus, I’m someone who can’t stand inactivity. In a corporate development environment, there is often lots of slack space between the bouts of activity.
Most of this slack time is dictated by process (approvals, specifications, version control, build cycles, testing) and really can’t be hurried along – it takes what it takes to get certain things done. And I mean this in a very GOOD way.
I don’t really consider myself to be a “Cowboy Coder” – that is to say, a developer who prefers working alone, or goes “dark” disappearing for days on end and magically appearing with working solutions, eschewing things like documentation, process, and code reviews. On the contrary, I have been the director at a couple of companies where I walked the corporate development “walk” for years on end.
If I say which mode of development I believe to be the best I’ll surely start a shit-storm of protests from each side.
All I’m really doing here is just observing that I noticed how much my own personal perspective has veered over the years, because of how my development business operates, versus working in a large company where personal accountability is secondary to development process in general.
And I must say, I prefer being able to hold a single developer accountable, present company included, for their code and development practices. It is how I judge my own effectiveness, and how I judge the merits of other developers I engage for hire or work with.
I’m certainly not saying that this doesn’t happen in larger companies – it does. Over time, developers in larger shops know who produces great working code and who the dead wood developers are. It’s just that the consequences of being a dead wood developer in a large shop are usually not very punitive and in many cases largely ignored owing to the fear of losing even the smallest of productivity garnered by the under-performers.
As a result, over time, most companies wind up with a large cadre of very average developers.
Gerald Weinberger wrote about this some twenty years ago (I’ll have to find the reference – brain too addled at the moment) and I have found it to be true in my first hand experience.
Having a large group of Cowboy Coders (or even one in most cases) on your team is also less than desirable.
Who wants to work with a team of guys and gals who thinks they are right 100% of the time and everyone else are idiots? (OK – those of you who work with Doctors and / or Lawyers really don’t have to answer that – it’s a rhetorical question). High maintenance employees, while capable of spectacular results, often are the Barry Bondses of the Corporate World.
Sometimes, it’s just not worth it to put up with their shit just to meet a deadline (sometimes it is – knowing the difference is what makes great businesses and business models).
If I get a little time later in the month, I’ll try to wrap my head around making this a more cogent exposition. For now, you poor mugs are left with this mess.
Here’s a few Handy Tips on Moving FireFox and Thunderbird Profiles
One of the dangers / side effects of being in business over the course of several years is that soon you find yourself forgetting more than you know. You begin to notice once you outlive two or three (or four or five) laptops. Before too long you realize that that project you once could recite in your sleep is now some 8 or 9 years in the distant pass and you can’t even remember the user id you used to get into the system in the first place. Trust me – it’ll happen.
That being said, there are some practical things that this every 2-3 year “migration of the machines” teaches you about what is important. Namely, travel light and carry only what you must.
In real life, we have moved 5 or 6 times since 1999. In each move, we have discarded more and more stuff that once seemed vital, until we realized that it was just stuff that we had moved several times, and never used in a real sense. Bye-bye useless stuff.
Over time, one winds up with only the things that are really needful.
The same is true with your digital life. That application you wrote in comp sci is never gonna be used. Get rid of it. The cool app you wrote two employers ago and sitting on your keychain drive is never gonna make you the next Kevin Rose, Mark Zuckerberg, or (name your favorite uber geek). Get rid of it.
Before we throw all the babies out with the bath water, there are important items that we must / should / need to carry forward as we move from that old doorstop to the new hotness. Namely, our browser settings and that modern equivalent of race memory, our email data store.
Me – I use Firefox and Thunderbird. So, I’ll show you how to relatively painlessly move your Firefox Settings and Thunderbird Settings, along with all of your email, to a new machine. Ready?
First, setup your new laptop and install Firefox and Thunderbird, but do only the minimum to get the software up and on its feet on the new box.
You will need to be logged in with Administrator Access in order to do the following.
Somewhere on your old Windows machine (OK, Apple fan boys – stop your snickering), there is a directory named Documents and Settings. Sometimes this is on C, I mostly find it on D drives. Change the folder view properties so that you can see all hidden directories and files. You will see folders for each user defined on your machine. Find the folder for your user credentials and open that folder.
There are two directories that we are interested in – Application Data and Local Settings.
Under Application Data, there will a Mozilla folder and a Thunderbird folder. You will need to copy both of these directories to their counterpart areas on the new machine (under its Documents and Folders/User Profile/Application Data folder).
Navigate back to the Local Settings folder. Notice that it also has an Application Data folder. Drill down, and copy the Mozilla Folder and the Thunderbird folder to the new laptop’s corresponding areas for these folders.
That is the abbreviated methodology.
In practice, if you have two or three years of email, you’re probably talking about a few gigabytes of email. This may involve an intermediary machine to offload the data first – your mileage will definitely vary. For me, it took a few hours to first offload my email to my wife’s Apple iMac (it had the big hard drive that wasn’t being used, Apple boys, so it made the perfect thumb drive) and then from the iMac to my new-ish laptop.
I would be interested in hearing a similar methodology for (a) Outlook or (b) Apple Mail.
And I hope this helps some poor soul wondering how in the hell they’re gonna make this happen.
Disambiguating Beta
Just a few additional words, oh gentle reader, on the unintended consequences of (mis)using words in contexts that rob them of their original meanings.
Specifically, how the term “beta” has been co-opted by web developers in general (and Web 2.0 services specifically and most egregiously) to pre-excuse poor software offerings.
Originally, “beta” was meant to connote software that was at least 1 iteration away from being ready from release, and indicated at some point there was some “alpha” software in the recent past, with the following loosely understood meanings:
- Alpha Software – functional, but barely operational with most final features stubbed out but not fleshed out
- Beta Software – software that was essentially feature complete, but was not fully unit and system tested
The term “beta”, however, has been totally misappropriated. Now, every new web service, site, social networking silo, or mashup feels compelled to slap a “beta” icon across its logo and call it a day, support-wise.
In other words, attributing “beta” to your site is now supposed to connote that you will not reliably support the site, the software will be unreliable in its delivery, and the user “community” is expected to ferret out all issues with no compensations or rewards (or acknowledgment).
Is this the height of what we want to put out there, as developers and entrepreneurs? Poorly supported software and services that we acknowledge to be sub par years into its lifetime (I remind everyone, Google News was in Beta for like two years – the current record holder)?
If you are a Plaxo or a Spock (just to name a couple among the hundreds that do this) you should be ashamed to still be exhibiting beta in your logo. There should be a statute of limitations on using beta to excuse poor execution. Even Twitter, in its craptitude of unequal delivery, owns its craptitude by not claiming it’s beta software. I don’t see “Twitter – Beta.” Nor do I don’t see “Facebook – Beta” for that matter.
Own your software – for good or bad.
We let these “beta” services slide because there is no pain involved for us. We’re all getting a free ride, and the underlying theory is that we are getting something for nothing so we should just shut the hell up.
As users of these services, we deserve better, because we are the ones serving up the content and traffic for these sites. We may not be paying an upfront outright financial prices, but we certainly are paying the price in lost productivity and time wasted helping solve other people’s execution issues and bugs, gratis.
Another FBJS Gem that Caused Me No Little Grief
While the Facebook Developer Documentation has gotten somewhat better, there are places where it is out and out – well – wrong.
For example, then using the addEventListener function connect events to an object, the Facebook documentation says that the third parameter for capture is not used. WRONG.
How do I know this? Well, because I had need to attach both a blur and a change event to an inline edit control… and when the 3rd parameter was left missing, the blur event never fired. Adding false to the third parameter allowed both events to fire (see code below).
if (document.getElementById('inlineEdit')) {document.getElementById('inlineEdit').addEventListener('blur', blurInlineEdit, false);}
if (document.getElementById('inlineEdit')) {document.getElementById('inlineEdit').addEventListener('change', changeInlineEdit, false);}
One of the big challenges in writing Javascript (er, FBJS) for Facebook Canvas Pages is seeing what gets broken by Facebook’s munging of Javascript. By and large, things hang together pretty well. Events, however, probably cause me more grief in debugging Facebook applications than any other area of development focus.
Logorrhea 