The platform argument is not too far from the language argument and the principles that apply to the one are just as useful to the other. However, since my focus today is platforms, I will stick to the one term while encouraging you to think of the other as you read along.
As a developer/architect and ofter observing the experiences of many colleagues and technology ventures, I believe three principles should rule our choices because they have been used to ensure success in just about every industry:
The customer is always right.
This one comes from the world of business and is, perhaps, the least favorite quote of many developers, so it bears some explaining: the customer hands over his/her hard-earned cash to your boss so he/she can pay you; no customer, no money for you. It's that simple.
Of course you can and should educate customers but, in the end, you have to meet them where they are. This, however, does not need to be too painful to put into practice. After all, no platform stays the same or at the forefront too long anyways. In a sense, the dominant platform is like the weather; if you don't like it, just wait for it to change.
You fight a with the army you have, not with the army you want.
No doubt from the military world, this principle is that of practicality within constraints. Way to many developers are crybabies who think it is a sign of class to be seeking ways to prove why certain things cannot be done. I would like to remind these developers that the software development is, if anything, "the science of possibility" — not impossibility. Even in the technical world, consumer choice is fickle. Once a platform emerges as dominant, there is very little we can do except meet our customers there. Our value as "scientists of possibility" will be proven by our ability to creatively get around the limitations of the platform du jour.
The end justifies the means.
Often quoted in the political world, I hesitated to quote this principle because it has often been used to excuse atrocities. A more palatable translation would be "do whatever it takes to get the job done." This principle is not difficult for developers to embrace, however, its application isn't always consistent or well understood. Two terms whose definitions are often muddled are "job" and "done." Not very big words — way below the $64 price point — yet contentious. What is a developer's job and when is it done? A software developer/engineer's job is to provide software in the same way in which a builder delivers completed homes. This means that the developer needs to appreciate the user's point of view — as opposed to ridiculing it, as is often the case— and use whatever platform or tool necessary to deliver a product that meets user acceptance. I am a firm believer in UAT although too many developers hate dealing with it.
Does this mean that developers should not evaluate platforms and develop criteria for evaluating the best? No. In fact I encourage developers to be continuously evaluating platforms and play favorites. This is not only important because, as engineers, we often play the role of consultants but also because we may end up creating our own platforms one day and need to have clear in our minds what makes one platform better than another. So, learn to select and learn to justify your choice using technically sound, logical arguments.
A good way to choose a preferred (or reference) platform is to make a wish list of all the things that a platform should have. Make sure you take into account not just your needs as a developer or your approval as an engineer but the user's/customer's needs as well. Once you have completed this list, use it as your basis for choosing among the existing ones. Or, better yet, build your own — although that would be venturing into venture capital territory and the subject for a whole other post or type of blog.
No comments:
Post a Comment
Care to comment? Have a question? Type your thoughts right in here :