Outsourcing and the economy

I watched a prior employer systematically send software engineering jobs to India, giving all domestic software engineers the option of becoming software analysts or showing themselves the door. Despite this, I like to think that I have a fairly open view of offshoring, globalization, and our place in the economy. While at first I was very angry with the decision and spent a good bit of time vehemently discounting offshoring, I have relatively recently come full circle to the view that offshoring is good as long as it is in the right context.

Cheap labor is nothing new. People have long complained about losing jobs to workers willing to do the same job for less money but the problem typically reaches a boil when the invading workforce is nomadic or the employer seeks foreign investments. This is because many see this job loss as a negative impact on the economy and their livelihood. However, just because a job is lost to an overseas competitor doesn’t mean the effect on unemployment is a negative one. Unemployment only encompasses those unemployed individuals who are actively looking for a job. Individuals who are not actively pursuing employment are not counted. The majority of domestic employees can find another job once theirs has been outsourced. It may not pay as much as they are used to or may be “a step down”, but it is still employment. For the most part we can ignore the negative impact on the economy as a result of offshoring. In fact some studies even show that offshoring has a positive impact on unemployment rates.

So if the economic argument for maintaining domestic jobs breaks up, what is left? Pride. The fact that we have lost our jobs to someone who is willing to work for far less injures our ego and leaves a bitter taste in our mouths for globalization (I can personally attest to this). To help illustrate the positive side of this trend we must change our perspective and look to the supply and demand of labor in the job market.

Assuming a successful service or product, the early days of an industry create a high demand for workers to maintain adequate supply for consumers. Assuming that consumer demand remains high, so will the demand for workers. Because of the perpetual demand for workers and the desire to maintain high profits and low costs companies will find ways of optimizing and improving processes to the point where they are at their optimum level of efficiency. Once a process reaches a point where it is at its most efficient, the action of executing the process takes second chair and becomes an exercise in following a well rehearsed script. At this point it is relatively easy and cost effective for companies to ship production and processes offshore where they can achieve the same results for a much lower price.

When this happens, the domestic employees are left with three decisions: don’t work, find another position utilizing the same skill set, or improve their skills. Most workers will opt out of the first option as a lack of income severely hinders one’s lifestyle. The second option is a likely jump for most employees however this option will only be viable for as long as there is a domestic job within their skill range. Once the domestic positions have dried up the deposed employees will be left with only the first and third option, meaning most will opt to improve themselves. This improvement ushers in the next phase of the cycle and brings us full circle back to where we began: employees are helping to drive towards efficiency in an economy.

The economy we now find ourselves entering is one where labor, and thus hardware, is cheap and readily available and information is truly where the power and money lies. Just look to companies like Apple and their designs for proof of this. The next phase of this cycle has already begun. The information economy is already starting to be shipped to less expensive venues and the domestic economy, at least in the software world, is starting to move towards an architecture and design economy where product specifications and OOD are pounded out here and then shipped overseas for quick assembly. The same concept can be seen in all industries, as was illustrated with the link to Apple hardware above.

The shift from an agrarian society to an industrial society took a long time. The shift from an industrial society to a data society took significantly less time. Already we are seeing the dawn of a knowledge society were data is just the avenue of exchange. As the working medium becomes more pliable we will see this trend continue to speed up. So how can you make sure you aren’t left behind in this cyclic evolution? Stay abreast of the trends and tailor your learning to accommodate. It is when we stop being mad at outcomes and start looking for opportunities in them that we will truly help ourselves and our economy truly excel.

On Hubris

Pride has its place. You should take pride in your work, your family, and things that you do. It is when this pride becomes excessive that there are problems. The right amount of pride will ensure that the highest level of quality is achieved in everything we do because we will check and check again to make sure that the work we do is up to par with what we consider correct. However, slightly too much pride can tip the scales and usher in carelessness. When we think we know it all we let down our guards and have a tendency to stop second guessing ourselves, which increases the probability for mistakes.

Programmers, for the most part, are a pretty positive bunch.  We tend to think we can solve the problems of the world through a couple well constructed key strokes. While we often have the best of intentions we are also fallible and find ourselves backtracking to undo our mistakes on a regular basis. The difference between developers that spend a lot of time backtracking and those who spend very little can ultimately be boiled down to pride, ceteris paribus. So how can the typical developer keep a tight leash on hubris? Write test cases.

When developers begin to assume that they are too good to need to write test cases problems often follow closely. Test cases form the foundation for unit testing, refactoring, and new development and serve as a base to which developers can use to ensure that their changes did not have any unintended affects on the system at large. Test cases are simply good programming practice and should be an essential part of any developer’s repertoire.

Teach Yourself Software Engineering in 15 Minutes (or not…)

As professionals we should, for the most part, find ourselves in a perpetual state of learning. It is when this trend of a ferocity for consuming knowledge subsides that we find ourselves bordering on mediocrity and threatening to fade away into the abyss of the typical. As a junior, mid and senior level developer I was constantly reading. Looking back I now wish that I had, at times, chosen different content, however I still give myself kudos for reading something.

As part of the shift from a mid level engineer to a senior one I began taking part in interviews, a process that has left me confounded at the masses of software engineers that consider themselves to be senior level but are anything but. My wife has mastered the lingo and many of the buzz words of the industry simply from being around me for my years of service to the software industry. However, the difference between my wife and many buzzword slinging prospects is that my wife will openly admit where her knowledge is lacking. Job candidates, however, often do not. I am continually astounded when I ask a “senior” level engineer for a couple books they have read only to find that Sam’s Learn [LANGUAGE] in [TIMEFRAME] is the front runner in their literary portfolio. I must admit I have read some of these books and I actually think they have their niche in which they provide benefit, however you will never hear me mention them in line with Design Patterns: Elements of Reusable Object-Oriented Software, Refactoring: Improving the Design of Existing Code, or Effective Java.

I like to consider myself a very good software engineer – I study hard, I try and stay abreast of the industry, I practice hard and learn from my mistakes, and I pay attention to those who I have recently seen dubbed as software “rock stars”, people like Joshua Bloch and Martin Fowler. It pains me to see such a high number of software engineers that expect the longevity of their career to dictate both their status in the field and the quality of their output, as this expectation is a fallacy in its purest form. I have worked with many individuals who possessed unbounded potential but refused to apply themselves. Likewise I have worked with many whom have had unbounded potential and have applied themselves, many of which I expect to some day see in that ever expanding “rock star” clique.

The point here is simple. Those who read and apply themselves will, talent willing, find themselves moving into the upper echelon of the software world. Those who don’t are destined to remain followers of the software elite. Don’t believe me? Check out The Mythical Man Month and pay close attention to the emphasis that Brooks continually places on the programming elite.

Of course the true irony of this post is that the intended audience is unlikely to ever read it.