Getting Your Customers To Change Their Ways

We programmers talk about getting rid of accidental complexity so that our code contains only essential complexity. And business processes are what we think of as essential complexity. Fair enough. But business processes have accidental complexity as well. Business processes suffer from poor maintenance over time. Business processes need to be refactored as well, and when you have a project to automate a process, you have a certain amount of freedom to challenge the process, to prod and poke it, to question it. Don’t assume that you have to take it as entirely given, a set of requirements cast in stone.

-Raganwald

I've mentioned the whole accidental complexity thing before, although not in terms of business processes. Reg's post is a great read (and well worth a look), but the post points to an even deeper issue in software development: Trying to convince your customers (or stakeholders if you prefer) to change their business processes.

Now all software developers, in the course of working on some project or another, have always come against some workflow issue and said to themselves, "why the hell do they do that?" I have had plenty of those situations (far more than I'd like to admit, I think) - especially on a recent project. In many cases, instead of trying to point out the problem, we'll happily plod along and do what the customer asks rather than tell them they need to change how they do things. In this sense, we're just as liable for the problems of process complexity as the customer since we don't point them out when we see them.

But one big reason we're content to just shut up and code is because the customer pays the bills: They ask us to build something and we build it. In a lot of situations, they don't want us telling them how to do whatever it is they do - they just want us to build them something. Period. End of story.

Sidebar: This is especially the case in the government sector - where trying to get some organizational unit to change it's business process can take years to do, and may even require action by congress. This is a big reason we get projects like Virtual Case File as results - not enough critical attention is focused to the business processes, since nobody really has the capability to make immediate changes. A bureaucratic (or otherwise complex) process will result in a bureaucratic software system (if it can ever actually be implemented in software, which is not very likely).

So how do we tell the customer/stakeholder to change their business process?

I don't think there's an easy answer to that, since every situation is different: Some customers are simply more receptive to such suggestions than others. I guess the first part of the solution is to make sure you're working with the more receptive customers before you start the project...that way you can avoid the headaches altogether.

Probably the best way to get a customer to change a process is to show them: If you're developing a software solution that follows the business process in question, than being able to show the customer a prototype of a more streamlined business process might help get the point across in a better way than simply saying, "Hey, you're process is flawed. We should look at improving that first" ( and if you're following some rapid development process like XP, or other agile method, this shouldn't be too hard to do.)

If nothing else, this should at least help open a dialog between you and the customer (And we all know how important communication is around here, don't we? :-).

Having that kind of dialog with the customer is the key to getting the customer what they actually need, rather than just what they want.

Adobe moving to Flex-ify the mobile market?

After my last posts about the iPhone, now comes word that Adobe's moving forward with an iPhone version of the Flash player. This, despite the fact that the iPhone SDK license prohibits interpreted code (which has put the brakes on Sun's aspirations for an iPhone JVM).

How is Adobe going to reconcile the licensing issue? I'm not entirely sure. But it seems that Adobe probably has a good deal of leverage in getting Flash support on the iPhone. For one, given Adobe's extensive track record on the Macintosh platform - an entire suite of applications that have long been associated with Macs - they may have a little more sway over getting the Flash VM (or some variation of it) on the iPhone than perhaps Sun would have in getting the JVM supported. Adobe has a long standing history of support for Apple's systems, so I don't think Steve Jobs would want to piss off one of his biggest supporters.

Also, considering the large number of sites nowadays that take advantage of Flash in some way or another, not having the Flash player available on the iPhone effectively cuts off the user base from a significant portion of useful services. I'm sure the users might also put pressure on Apple in to support Flash (if they haven't been already): Being cutoff from popular sites such as YouTube, for no reason other than some licensing snafu, is likely nothing short of irritating.

Coupled with the iPhone situation is the recent deal Adobe made to put Flash on the Windows Mobile platform. Of course, the web experience reason given for the iPhone also applies here: User don't want to be limited simply by not having a Flash player on the system. Windows Mobile already has a pretty large user base - it's been around for much longer than the iPhone - so having Flash available on Windows Mobile devices definitely make sense.

This all seems to signal the intention of Adobe to move into the mobile development marketplace: Having Flash on the likes of the iPhone and Windows Mobile opens up both of those platforms for Flex, since it's a fairly small extension to the existing Flash platform. And since Adobe has no real presence in the mobile space, it has a lot to gain by extending it's Flex application development into the mobile market.

Whether they are more successful than Sun has been with Java Micro Edition is anyone's guess. Sun has enjoyed limited success in the mobile market - they've made inroads, but as this article I linked to in a previous post explains, it hasn't been what Sun would ultimately have hoped for.

The good part of Adobe's push seems to be that they are focusing on the Windows Mobile and iPhone platforms, rather than the individual mobile phone suppliers themselves (at least currently). iPhone licensing aside, both of these platforms are considerably more open to 3rd party development than other phone systems that are directly in the control of the mobile manufacturers. Of course, both of these platforms are used on phones that are significantly more sophisticated (and higher priced) than a standard mobile phone, so the user experience would be limited to those that can afford the more expensive smart phones. But as the devices become more widespread, this obviously will open up the user base even more. I think the iPhone has helped in this regard, as it's clearly shown what's possible in a smart phone and has expanded interest in the smart phone market.

And adding both Java (including JavaFX) and Silverlight to the picture also opens up the competition for the mobile development marketplace. Should these technologies make significant inroads into the mobile market (which I would expect them to if Adobe continues it's push) it means nothing but good things for future mobile applications as all three companies compete to bring the best development capabilities to mobile devices.

More iPhone Musings

Following up on my previous post about Java on the iPhone, I came across this (via Raganwald...again).

I liked the article on the whole, as it provides a good deal of background information. Many of the articles I've read on RoughlyDrafted previously contain a nice amount of history in each article. But in this particular case it seems they go through a great deal of back story just to say "Apple doesn't need Java on the iPhone". That's all well and good: But the license accompanying the SDK pretty much makes the idea of Java on the iPhone a non-issue, since it doesn't allow for code interpreters (This probably also explains why Jobs stated that there'd be no Flash on the iPhone: If he allowed for Flash then released the SDK with a license disallowing applications running interpreted code, all hell would have broken loose).

Of course, being a rather Apple-centric site, I can't say I'm surprised by their take on the idea of Java on the iPhone. I do certainly agree with most of what the article says - Sun has had a hard time with Java Micro (and Java on the Mac is in disarray at the moment, too) - but I think they're making a mistake by assuming that Sun would have simply ported Java Micro over to the iPhone. Based on the comments made by some people at Sun, it sounded more like they were interested in making a more robust VM for the iPhone and not just a JME clone.

Of course all of this is irrelevant at the moment: Apple's license for the iPhone SDK currently forbids something like Java.

I still think that removing the idea of Java and Flash/Flex for use on the iPhone is a mistake: Apple may not need to have these technologies for continued success, but artificially limiting what can be run only removes additional avenues of innovation for the iPhone as platform. For one thing the shear number of developers working on both Java and Flash/Flex could be leveraged to Apple's advantage.

Just because you don't like something doesn't mean it can't be useful in some way.

The Job Interview as a Game

One weakness that I've come to recognize in myself is that I'm terrible at interviewing for a job. I mean seriously...I suck. Always Have. And it's not like I don't know how to do the job for which I'm interviewing, it's just that when it comes to face-to-face interviews I tend to struggle and have a hard time getting the point across that I'm a damn good software developer.

Part of it may be that I don't have that salesman mindset - that mindset that requires you to be able to at least bullshit your way through some part of an interview. Maybe not bullshit...maybe just the personality traits that allow someone to properly convince others of their great programming skills (When it comes to software development you rarely want to have someone that can bullshit their way through an interview, and most interviewers - the competent interviewers, anyway - have some form of BS detector with which to weed them out.)

In either case, being of the software developer mindset - that of constantly trying to figure out the "right way" to do things - I've tried to analyze the problems I've had with interviews and improve my interviewing skills...to varying degrees of success.

Over the course of a few interviews I've managed to uncover and...well..."hack" at least one problem, which is my shy nature: I have a hard time talking to people I don't know well, or am not familiar with in some way. I think many times I've done interviews my shyness has made me come off as having an anti-social personality...perhaps even made me appear arrogant (I've never confirmed this for sure. It's just a feeling I get from the interviews I've done.) Definitely not good qualities to show during an interview.

Nevertheless, that's one issue that I've been able to deal with in a few recent interviews by giving myself sufficient motivation to open up and engage in conversation more freely (job interviews in themselves are usually good motivation, since I'm trying to increase my personal income by looking for a new job).

So that's one problem down...

Another problem I have to overcome is my somewhat cynical nature about the interview process: I've come to regard the whole thing as a rather lame song and dance (or whatever metaphor you think fits) where I basically have to stand in front of people and say "Hey! Look at meeee! I'm the awesomest developer out there!" And...way too often...the people I'm pandering too have no flipping idea what I'm talking about when I mention technology X or framework Y during the interview, cuz they're not the technical people and I'm just supposed to convince them that I'm good based on how I act rather than what I actually know.

The simple solution: Stop interviewing with lame-ass people like that. I've basically tried to avoid the whole recruiter mess (which is kind of difficult since the area I'm in seems to be bursting at the seams with more recruiters than actual jobs).

But my overall attitude about the process hasn't changed much: I think it's stupid and aggravating and annoying and...well you get the idea.

So then yesterday Stevey talks about getting that job at Google in his latest blog post, and gives some advice for would-be interviewees.

Best. Advice. Ever.

For those too lazy to read through one of Stevey's post (they do tend to be rather long...but well worth reading), here it is in a nutshell: Treat the job interview as you would a final exam - study and prepare beforehand. Expect just about every damn question ranging from the basics to the advanced stuff and leave nothing to chance. Practice, practice, practice before the interview.

I'd maybe even go further than this and say that perhaps you could even treat it as a game or a puzzle. One where you're trying to figure out the best solution as quickly as possible in hopes of "winning" a job. In this way, you need to prepare for the exam/game/puzzle by boning up on all manner of subjects that would give you that extra edge.

Thinking about it...maybe you'd want to treat the interview as though you're going on the game show Jeopardy: You'd want to study and test yourself on all manner of subjects ranging from the obvious to esoteric before getting on stage with good ol' Alex, wouldn't you? Based on Stevey's suggestions it seems like you should prepare in a similar manner for an interview as a software developer, too.

I think that's a damn good idea.

I like the perspective that Steve provides in his post: It's a welcome change from the usual "cheat sheet" style of most interviewing-related blog posts, which show a list of common questions that some interviewers like to ask. Knowing the typical questions that interviewers like is certainly nice, but understanding the underlying question of why those particular questions get asked is not usually so clear.

Plus I like the idea of preparing for an interview they way he describes. I think this is an area in my own job interviewing that I feel could help a a lot. I'm traditionally the type of person that likes to wing it, which after reading Steve's post I'm realizing isn't a very good idea.

Hmm....Be Prepared....I remember hearing that during my childhood somewhere...

One again: Communicate!

This blog post (found via Raganwald) reiterates what I've said previously: It's all about communication.

This is the single most important reason why projects succeed or fail.

This is also why I think The Mythical Man-Month is one of the most important books that any developer can read...even so many years after it's initial publication.

Seeing the "adding programmers to a late project makes it later" quote explained in detail is certainly interesting and worth reading, as is reading No Silver Bullet which also has some important points as well (and which I've even talked about previously, too).

But the single most import discussion in The Mythical Man-Month is about effective communication.

Fred Brooks recognized that maintaining effective communication is what separates successful projects from failures. The amazing (or distressing) thing is that he understood this well over thirty years ago. It sometimes seems like that message got lost while everyone focused on his discussion of complexity and the whole "adding programmers to a late project" that everyone loves to quote so much.

As developers, we have a habit of finding ways to shut out the world...which is certainly necessary sometimes to get the job done. But we have to be careful to not cut ourselves off so much that we're not keeping key people on the team out of the loop about our work. It's a delicate balance that has to be maintained, but it's important that everyone involved in a project has an idea of what's going on - whether you're a manager, architect, developer, or user.

To do otherwise is to invite failure.

iPhone SDK Could Mean Big Things for Java (and Flex?) Developers

So I saw a little blurb this weekend on Slashdot pointing out this InfoWorld article. It talks about Sun's intention to port the JVM to the iPhone.

At first I was a bit ambivalent towards it: Sun certainly has the experience and capability with the Java Micro Edition to make this happen, so I have no doubt it will (unless Steve Jobs tries to put up roadblocks for Sun...which would be monumentally stupid if you ask me). But since most of my own work has never really touched the mobile space, I wasn't particularly overjoyed by the announcement. I thought it interesting, but that was about it.

Of course, I didn't initially RTFA, either. So after taking a closer look, I think this could be the start of some big things for the iPhone. And not just in terms of Java development.

For one, the article quotes Sun's desire for developers to port ERP and CRM apps to the iPhone. While I'm not sure how feasible that may be (depends on the JVM implementation, and the nature of the applications themselves, of course), it signals a desire by Sun to help make the iPhone a full fledged platform for businesses to take advantage of. And also considering the number of Java developers out there, this could provide a huge boost to iPhone's dominance in the future with having such large developer pool to draw from.

But something else that caught my attention in the above article was the possible implementation of JavaFX on the iPhone. Even though a release of a JavaFX implementation is further down the road than just a usable JVM, this could prove to be a huge boost for Sun's framework.

And this would obviously get the attention of Adobe, opening up the likelihood that they will step in and deploy a version of Flex for the iPhone as well. Even with Steve Jobs' mentioning that he didn't have plans to include Flash (which is what Flex uses) on the iPhone, there would be nothing stopping Adobe from doing something similar to what Sun is doing with the JVM and implementing it's own streamlined VM for the iPhone (or even just some performance tweaks so it runs acceptably).

So, with the release of the SDK , you have Sun - and potentially Adobe - both battling in iPhone-space to develop mobile applications. The future of iPhone development could be huge for both Java and Flex.

Of course, it's just speculation whether Adobe would jump into the iPhone world, but I think if Sun's heading down that road it's a good bet they will, too. The potential market there is probably hard for anyone to ignore (which is probably why Sun's even considering a Java version for the iPhone in the first place).

But this is all contingent on whether Steve Jobs attempts to quash what Sun is planning for the JVM. I think it would be a big mistake if he does that, though: Shutting out new avenues of innovation on the iPhone (not to mention the huge developer base there is in the Java world) would unnecessarily hamstring further popularity of the platform.

I'm anxious to see where this goes now. The iPhone has a huge following and having Java (and possibly JavaFX and Flex) development in the mix opens up all kinds of potential for the iPhone as a platform.

One of My Favorite (and Most Productive) Developer Tools

In my career as a developer, I've constantly tried to work with new - or just different - tools: I've jumped editors from Emacs to Netbeans to Eclipse and back again (and still do when I have an itch for something different), worked with build tools the likes of Ant, Maven and make, and messed around with just about every popular (and not-so-popular) programming language out there at one point or another. All in an effort to both explore technologies and to find ways to be as productive as I can.

But I've realized recently that, over the past several years, there's been one tool that has consistently allowed me to be the most productive possible.

My MP3 Player.

First and foremost, being able to focus on my work is the first step toward getting anything done. And, seeing as I currently inhabit a cubicle, I'm forced to find ways to deal with a large number of distractions around me (and recently it's become increasingly necessary: Seems a rather obnoxious group of people has recently relocated to an area near my cube...lucky me).

Of course, every one of us knows that, as developers, we need more productive accommodations than a cube. I would love to have the type of work environment the likes of developers at Fog Creek or Google have, and the likes Jeff Atwood, and Joel Spolsky advocate - I have had that type of workplace previously, so I know how wonderfully productive it can be - but realistically not many companies out there provide such a workspace. It's unfortunate, but that's the way it is and many of us just have to deal with it.

So I do what any other code jockey out there would: I tune everyone out. Literally.

Currently, I use an iRiver H320 (Although certainly good players, I tend to avoid the more mainstream choices like iPods or Zunes...if nothing else than to just be different). So far the iRiver unit has been a worthwhile purchase: It meets my current needs (i.e. drowning out the commotion around me) and I'm happy with it.

Player choices aside, even if I had a private office with no distractions at all, I'd likely still pop in the earbuds and listen to my music player. I've found that my best coding work has been done while listening to a steady stream of music. Usually, with the right music playing, I'm able get myself into the zone and stay there for extremely long periods of time.

This might not work for everyone, but for me it's been an invaluable asset to my productivity and one of the best tools I could ever have when developing software.