To be honest, I do not believe that people will move from an iPhone to an Android handset because it happens to have cool or 'must have' applications; I believe that people will move from one to the other because the Android platform is 'good enough', has enough of the same features, is cheaper than the iPhone. I don't buy into Steve Job's idea that quantity of quality applications is what matters - the statement pertaining to application quantity or quality is marketing fluff that works only when the sheeple take it in fully and lasts only fleetingly before the American populace is onto the next thing, keeping up with the Jones'.
I draw similarities between the marketing done for the iPhone and its applications to Rosie the Riveter. When the war was over and all the women who had been working to make the machines of war for their men who were off fighting were being told to go back to the house and the kitchen so that the returning men could have jobs, common marketing and media helped to reinforce the idea that doing so would be good allaround. You saw shows like Leave it to Beaver and other media outlets depicting the perfect house wives in high heels, cooking and cleaning. Eventually that pervasive depiction of the perfect house wife became a main steam understanding again and womens place was the house and home, the kitchen, doing house work in heels and having dinner on the table when their 'Man' came home.
People don't specifically need killer android applications in order to choose the Android Platform. They need something that is 'good enough' or 'similar enough' at a reasonable price. Given a choice people might choose the iPhone to have the same thing as a friend driven by pressure from their friend to purchase and pay the premiums associated - I believe what will eventually happen is that the pressure applied will dissipate, the need to keep up with the Jones' will dissipate and 'good enough' will do for most people. I do want Android to be a great platform, but honestly I think having something 'good enough' that allows me to do as I please with the device is much more appealing - voted with my dollars and purchased an Android phone when I could have gotten the iPhone 4.
Monday, November 22, 2010
Sunday, November 21, 2010
Feeling like a hero should be your sign, something is wrong
I was reading the following post on "Work Around Cultures" and got to thinking how many places I have worked or listened to friends of mine talk about their jobs and how all but one of the places I have worked and a fair number of the places that my friends work fall into the category of "Work Around Cultures". Now to be fair - the post is about Medical work places, but I believe it to be just as applicable to the software companies that I have worked for in my career.
The article points out that there are several consequences to what the author calls "Patch-It" work arounds.
1) Increasing medical error
Work-arounds lead to interruptions, which in hospitals are associated with errors and accidents. They increase the cumulative workload for nurses; higher workloads are associated with worse patient outcomes.
The same sort of issue can be found in IT departments and operations groups where work-arounds lead to interruptions and errors due to the work-around not being well documented or understood. Consider the following: a work around is done by one person, the next person that works on that system has to remember that a work-around was done or know who to go talk to about the work that had been previously done in order to work with that system. This can lead to errors and mistakes. Granted - the mistakes made are not generally life and death but can be costly nonetheless.
2) Wasting resources.
Individually, work-arounds don’t appear to waste much time, but studies have shown that required hunting and fetching eat up as much as 36 to 60 minutes per 7.5-hour shift.
As you can well imagine from #1, when you need to make a change to a system or need to make an operational change having to find an individual who made a work-around can be costly in terms of the time required to go track down the needed information. It would be my speculation that the amount of time wasted would be very similar to the numbers indicated in the article if not more. Having to deal with the work arounds will cause people a great deal of hassle trying to figure out what the work around was meant to do and who put the work around in place in the first place.
3) Promoting employee burnout.
Persistently lacking resources required to do one’s job takes physical and psychological tolls that lead to nurses’ burnout.
Again leading from #1 and #2, you can well imagine that people would eventually get very tired of having to go track down work arounds and the people that performed them. I can hear everyone I have worked with in the past saying something like "... I was not hired to do this, I was hired to X..."
4) Creates a work-around culture.
When work-arounds are common, people are less likely to seek system improvements. There’s an insidious aspect to the culture that causes people to dismiss notions of improving things and learn to live with imperfection.
Work arounds seem to beget work arounds similar to telling a little white lie that you then need to cover up with another little white lie or even bigger lies. I believe having to work around things in an IT culture equal to the idea of technical debt. There may be a good reason to incur debt and to perform a work around as long as you make the space and time to go and 'repair' the work around. Left in place how ever, work arounds can be a drag on the culture and lead people to believe that things will never get fixed. Worse - people my start to believe that the work arounds are EASIER than working to actually fix the underlying problems.
The article points out that having a work around culture can be compelling to people because it provides a way to get the job done. Paraphrasing and translating from the article the work arounds provide a way for the worker to 'get the job done', not involve the manager (keeping managers and works happier), and foster a hero like feeling. The work around culture however is terribly detrimental to the organization because it can translate into a compiling list of work arounds that might never be solved, possibly leading to the need for "The Big Re-Write" of the developed software.
“There’s an insidious culture of ‘That’s just the way it is around here.’”
— Anita Tucker
Managers can help alleviate this by setting a tone that indicates that they would like workers that report to them to report issues that they find. Doing so has to go hand in hand with actually doing something about the reported items but in most circles doing something about reported issues is the easy part. I personally work always to make sure I am attempting to address the root causes of problems and not just tossing a band-aid on problems. I don't like to repeat work I could have saved myself from doing it better or right the first time. What does your work culture support? If where you work would rather you patch it, work around it and ignores the root causes ... it might be time to look for a new job.
The article points out that there are several consequences to what the author calls "Patch-It" work arounds.
1) Increasing medical error
Work-arounds lead to interruptions, which in hospitals are associated with errors and accidents. They increase the cumulative workload for nurses; higher workloads are associated with worse patient outcomes.
The same sort of issue can be found in IT departments and operations groups where work-arounds lead to interruptions and errors due to the work-around not being well documented or understood. Consider the following: a work around is done by one person, the next person that works on that system has to remember that a work-around was done or know who to go talk to about the work that had been previously done in order to work with that system. This can lead to errors and mistakes. Granted - the mistakes made are not generally life and death but can be costly nonetheless.
2) Wasting resources.
Individually, work-arounds don’t appear to waste much time, but studies have shown that required hunting and fetching eat up as much as 36 to 60 minutes per 7.5-hour shift.
As you can well imagine from #1, when you need to make a change to a system or need to make an operational change having to find an individual who made a work-around can be costly in terms of the time required to go track down the needed information. It would be my speculation that the amount of time wasted would be very similar to the numbers indicated in the article if not more. Having to deal with the work arounds will cause people a great deal of hassle trying to figure out what the work around was meant to do and who put the work around in place in the first place.
3) Promoting employee burnout.
Persistently lacking resources required to do one’s job takes physical and psychological tolls that lead to nurses’ burnout.
Again leading from #1 and #2, you can well imagine that people would eventually get very tired of having to go track down work arounds and the people that performed them. I can hear everyone I have worked with in the past saying something like "... I was not hired to do this, I was hired to X..."
4) Creates a work-around culture.
When work-arounds are common, people are less likely to seek system improvements. There’s an insidious aspect to the culture that causes people to dismiss notions of improving things and learn to live with imperfection.
Work arounds seem to beget work arounds similar to telling a little white lie that you then need to cover up with another little white lie or even bigger lies. I believe having to work around things in an IT culture equal to the idea of technical debt. There may be a good reason to incur debt and to perform a work around as long as you make the space and time to go and 'repair' the work around. Left in place how ever, work arounds can be a drag on the culture and lead people to believe that things will never get fixed. Worse - people my start to believe that the work arounds are EASIER than working to actually fix the underlying problems.
The article points out that having a work around culture can be compelling to people because it provides a way to get the job done. Paraphrasing and translating from the article the work arounds provide a way for the worker to 'get the job done', not involve the manager (keeping managers and works happier), and foster a hero like feeling. The work around culture however is terribly detrimental to the organization because it can translate into a compiling list of work arounds that might never be solved, possibly leading to the need for "The Big Re-Write" of the developed software.
“There’s an insidious culture of ‘That’s just the way it is around here.’”
— Anita Tucker
Managers can help alleviate this by setting a tone that indicates that they would like workers that report to them to report issues that they find. Doing so has to go hand in hand with actually doing something about the reported items but in most circles doing something about reported issues is the easy part. I personally work always to make sure I am attempting to address the root causes of problems and not just tossing a band-aid on problems. I don't like to repeat work I could have saved myself from doing it better or right the first time. What does your work culture support? If where you work would rather you patch it, work around it and ignores the root causes ... it might be time to look for a new job.
Friday, November 12, 2010
Professionalisim (Software Engineering)
Software Engineering is a discipline much maligned by a fair number of people. Actually - what bothers most people is the idea that developing software is an 'Engineering' practice because it places software developers on a level playing field with civil, chemical or materials engineers (or any engineering discipline). Engineering disciplines require certifications and testing and a great deal of knowledge that all gets boiled down to 'permits' and other legal documents that determine an individuals qualifications to be labeled an 'Engineer' none of which software ENGINEERING has currently - all you have to do to be labeled a software engineer is 'develop software', that is it - no fancy diplomas, no permit tests, no other qualifications required.
There are some indications however that this is changing from the inside out. Software engineers would like to be considered highly professional people and are talking about what it takes to have professionalism in software engineering and have it represented as a top notch profession.
1) Your code must be clean
Take this point as you will - your code must be clean, easy to read, and easily maintained. You shouldn't have overly complicated methods, unrecognizable variable names, and just plain nasty nested if, else statements. Think twice about class files that are over 1000 lines long, methods that are over 5-10 lines long... take the time to take pride in your work (like me editing this ... again).
2) Your code should always include unit tests
Unit tests do two things - one they help you to validate that what you have written is what you intended and two they provide a way for you to verify after you re-factor to get to the first goal of having clean code that you have not broken anything. Unit testing provides a very critical safety net - you are lost without.
3) You should practice
Programming like anything else requires practice to make you better and to keep skills sharp. Doing programming katas in your spare time to exercise the skills needed to have clean code and always have unit tests is of vital importance to being professional. If you were in the NFL or baseball or any other sport or musical profession you would need to practice to keep your skills up - programming is no different.
4) It pays to be multi-lingual
The basics of programming are essentially the same no matter the language that you typically program in. Because of that - lots of programming languages often look very similar but have subtle differences in their syntax or effect when they are executed. It can be beneficial to know several ways to skin a given cat as well as to understand what tools are best suited to a given job.
5) Pair Program where possible
Learning can be a two way street (and often is) so it pays to pair with someone when you are doing work - you can have one person writing failing tests that the other person makes pass. It can be eye opening and enlightening to have someone to talk with and discuss ideas with while you are working on coding out the solution to a problem. you may find your self writing far less code than you may have otherwise if you include a partner.
Is it possible to be professional without the above items? Yes - I imagine that it is, but I believe that if you want to call yourself a professional software engineer, you should be doing the items above at a minimum and including everything else as just common place.
There are some indications however that this is changing from the inside out. Software engineers would like to be considered highly professional people and are talking about what it takes to have professionalism in software engineering and have it represented as a top notch profession.
1) Your code must be clean
Take this point as you will - your code must be clean, easy to read, and easily maintained. You shouldn't have overly complicated methods, unrecognizable variable names, and just plain nasty nested if, else statements. Think twice about class files that are over 1000 lines long, methods that are over 5-10 lines long... take the time to take pride in your work (like me editing this ... again).
2) Your code should always include unit tests
Unit tests do two things - one they help you to validate that what you have written is what you intended and two they provide a way for you to verify after you re-factor to get to the first goal of having clean code that you have not broken anything. Unit testing provides a very critical safety net - you are lost without.
3) You should practice
Programming like anything else requires practice to make you better and to keep skills sharp. Doing programming katas in your spare time to exercise the skills needed to have clean code and always have unit tests is of vital importance to being professional. If you were in the NFL or baseball or any other sport or musical profession you would need to practice to keep your skills up - programming is no different.
4) It pays to be multi-lingual
The basics of programming are essentially the same no matter the language that you typically program in. Because of that - lots of programming languages often look very similar but have subtle differences in their syntax or effect when they are executed. It can be beneficial to know several ways to skin a given cat as well as to understand what tools are best suited to a given job.
5) Pair Program where possible
Learning can be a two way street (and often is) so it pays to pair with someone when you are doing work - you can have one person writing failing tests that the other person makes pass. It can be eye opening and enlightening to have someone to talk with and discuss ideas with while you are working on coding out the solution to a problem. you may find your self writing far less code than you may have otherwise if you include a partner.
Is it possible to be professional without the above items? Yes - I imagine that it is, but I believe that if you want to call yourself a professional software engineer, you should be doing the items above at a minimum and including everything else as just common place.
Subscribe to:
Posts (Atom)
