You are currently browsing the tag archive for the ‘Career’ tag.

The recent furore that erupted over Microsoft’s ‘shifting’ of focus for Silverlight and their somewhat wishy-washy attempts to clarify their position illustrates a fundamental disconnect between the Microsoft machine and the lives and careers of the developers that use their tools.

An enterprise CIO will cast his eyes over his domain and see a wide range of technologies in use and although he will use his enterprise architecture minions to herd technologies in some direction, he knows that there will be a lot of varying technologies being used – the decisions about which technologies to choose are complex and in many cases dictated by the vendor of the product chosen by the business. Likewise, a vendor technology strategist will build products that use many different technologies in order to support the varieties in the market and their big customers. Standing outside the technical trenches it is obvious that there is no preferred technology and besides, taking a bet on any particular technical bias is risky and best left to successors. It is difficult then for these people to realise or even understand the low level religious technical wars going on amongst the troops that are assembling one tiny piece over the overall solution.

But just because you can’t see it, it doesn’t mean that developers hedging their best on one or another technology does not exist. The ‘religious wars’ that we are familiar with, such as Java vs C#, Ruby vs Python and Lisp vs Common Sense are a ubiquitous testament to the dedication, passion and possibly blinding fanaticism that developers have for their particular chosen technology. The reason for this is quite simple, developing senior skills in any technology means that the average developer has to largely ignore others. Average to good developers (I am explicitly excluding ninjas) are unable to be considered masters at two wildly different programming languages, paradigms or frameworks. It is difficult enough as is, to become a master at a technology during a measly eight hour day, never mind going home and spending a single hour becoming at master at another.

While it may be sensible to have broad ‘generalist’ skills, and to a degree most good developers do, in the current employment market the best way to get a well paid job or contract is to have in-depth specialist skills on the technology being requested. A senior ASP.NET web developer used to leading teams and delivering complex solutions will find it difficult to be accepted to take the same role and for the same rate at a Java or Rails shop regardless of how much time has been spent as a Java or Rails hobbyist. Ultimately most developers (especially expensive Western developers) have a market value that is only as high as the value of their detailed technical skills from their last gig – regardless of years of other skills and experiences. And while we may blame the developers for their lack of foresight, we perpetuate this problem ourselves during interviews by asking specialist questions that only a developer with current, hands-on and detailed technical knowledge will be able to answer.

So the mistake that Microsoft made during PDC in seeming to support the ‘Silverlight is dead’ message by overplaying their plans for HTML5 was to ignore the developers that passionately believe that their medium term futures are dependant on Silverlight. Here in the City of London, it seems that Silverlight is gaining ground in financial services applications and many developers are whole hog, full time into Silverlight development (at very high contract rates I might add). Their value for their next gig will be determined by how much demand remains for the Silverlight skills that they have developed and a message about the death of Silverlight means that they will potentially hit the street as a junior to mid level web developer next time around. Microsoft, it seems, made assumptions about the fanatical support of their .NET developers without realising that that support is waning and their technology base is so broad that there are technology battles underway across Microsoft’s broad technology base.

I was interested to see Mike Taulty’s take (a well known UK Evangelist) in his post ‘Silverlight *versus* HTML5? Really?’ where he neatly lays out the argument for their being a place for various technologies but he makes the mistake of being a marketing person looking at the overall IT problem rather than as specialist developer. I especially like his comment ‘On the question of investment in Silverlight – yes, I’ve made that investment too.’ – with all due respect to Mike, the credentials used to find his next job will not be for his Silverlight coding skills, but for his awesome evangelist abilities.

An attraction to developers of more open source frameworks is that their demand is more natural and organic – not subject to marketing budgets, product positioning and acquisitions by mega corporations. For front end web skills, developers are comfortable putting a whole lot investment in JQuery because it is not subject to any vendors product focus and has a lifespan determined by developer support rather than how many developers are on the engineering teams at Redmond or how Microsoft intends to tackle the iPad problem.

In my twenty years in professional software development I have made a few major shifts in my preferred technology. It is difficult, frustrating and takes a while to get up to the same rate of delivery – but you get there in the end. So if a Silverlight developer were to take the huge investment to develop for HTML5, then why even bother going down the Microsoft route? Developers are finding that frameworks such as Rails and Django are fun to play with after hours, will get the same result and don’t have the risk that Microsoft will, yet again, cut their value at the whim of this financial years’ marketing objectives.

Simon Munro

@simonmunro

Given a good enough specification software can be developed anywhere in the world, making it attractive to do it where people are cheapest, so where does this leave first world developers with expensive lifestyles?

The cost of developing software is largely in the cost of human resources.  Development workstations, tool licences, source control and bandwidth are negligible compared to the burn cost of the actual developer and it stands to reason that cheaper salaries should make for cheaper software.  The cost of people is influenced by a number of factors, such as the seniority, but what is interesting is the income demands of skilled people that have expensive lifestyles.  It is this phenomenon that has created the primary driver behind the outsourcing industry where people are clearly cheaper to employ in Bangalore than in London.

If we were to believe that same-skilled people are a fraction of the cost in another country because of their lifestyles, the obvious question to ask is why isn’t all software development outsourced and virtually no developers living in expensive parts of the world.  Making use of outsourced skills is a bit more complicated than simply mapping developer roles to commodity resources regardless of location and the quality of the final deliverable is affected by more than just the individuals’ technical abilities.

However,  the use of outsourcing models is increasing and will continue to increase.  It is the desire of ‘elite’ developers to work better and more efficiently that drives the practices and culture that allow developers to work remotely – which could be anywhere.  Use of test driven development, continuous integration, collaboration technologies, cloud deployments, GIT-style source control, Google Wave and other technologies are becoming mainstream and used, not by the select few, but the masses of developers spread all over the globe.

So why is there still on-site and insourced development work still available in London or New York?  How should developers align their careers in order to be safe from the axe when some large chunk of business gets moved to a cheaper location.  Below are some styles of development that still seem to retain the services of expensive people.

1. Shortest Route

A lot of one or two man consulting gigs that exist for a few months cannot make use of remote resources because the business wants the work done simply, fast and now. The effort and time involved in finding remote people, writing a specification, getting all the infrastructure in place and the communication latency is simply too much overhead to bother with.  It is easier to have someone who can come on site, have a meeting, sit down and get coding.  The sort of work tends to be short-term, fiddly and with little disciplined project management.

2. Big Branded Consulting

Big consulting companies have the scale to offer services that include any combination of people and skills for fairly high rates and are able to pull it off because of their brand and penetration in the customer.  Big consulting companies have some really good people (often not even technical) that are able to open up opportunities and allow commodity developers to step in and do the work – keeping the customer is happy.  (Of course they can also switch out to outsourcing models when it suits the deal.)

3. Product Centric

Being a specialist on some specific product doing ‘configuration’ development allows developers to be seen as part of the overall expense of implementing a particular package, rather than a per hour development resource.  It doesn’t even matter if the work is technically difficult, as long as it requires an intimate understanding of a product for which there are few generally available skills.

4. Integration

Getting data from one system into another, no matter how simple the technology, is no trivial task.  There are undocumented ‘business rules’ that need to be catered for, confusing mapping and changes to processes that have to be uncovered on site and in person in order to coax an interface into existence.

5. Responsive

Some businesses need to be close to their development teams, be that for real business reasons (such as financial traders) or because the business model is trying to change the world – in some cases it is good to have a trusted development team with a track record.  These teams are generally responsive to the needs of the business and are able to churn out systems and features that delight the users at a predictable and valuable pace.

6. Startup

The startup culture is more than just about getting software developed for the lowest possible price.  Startups need to be agile and responsive and all staff at a startup have to have a special relationship that goes beyond handing out development tasks.  Startups, by the nature of how they operate and market seem to need to be located physically close to where the buzz is happening in order to get attention.

7. Bleeding Edge

Some individuals or groups of developers are able to market themselves as leaders in a particular technology, stack or approach and find that work will always come to them.  This group doesn’t have it easy though – what is bleeding edge now is mainstream tomorrow due to their own efforts and they have to continually reinvent themselves and discover new paradigms to shift.  Although a lot of developers aspire to be in this category there is little room and it is highly competitive.

 

So if you are a developer sitting in a first world country wanting to justify the rate that matches your lifestyle ambitions you need to be constantly aware of the value that you are adding to the people who are paying you to write code.  If you are looking at making lots of money being a generic, commodity developer then you face stiff competition from literally millions of people who can do the same thing.

Make sure that you find a style that is valuable and has a future as you chart your career.

Simon Munro

@simonmunro

More posts from me

I do most of my short format blogging on CloudComments.net. So head over there for more current blog posts on cloud computing

RSS Posts on CloudComments.net

  • Free eBook on Designing Cloud Applications
    Too often we see cloud project fail, not because of the platforms or lack of enthusiasm, but from a general lack of skills on cloud computing principles and architectures. At the beginning of last year I looked at how to address this problem and realised that some guidance was needed on what is different with […]
  • AWS and high performance commodity
    One of the primary influencers on cloud application architectures is the lack of high performance infrastructure — particularly infrastructure that satisfies the I/O demands of databases. Databases running on public cloud infrastructure have never had access to the custom-build high I/O infrastructure of their on-premise counterparts. This had led to the wel […]
  • Fingers should be pointed at AWS
    The recent outage suffered at Amazon Web Services due to the failure of something-or-other caused by storms in Virginia has created yet another round of discussions about availability in the public cloud. Update: The report from AWS on the cause and ramifications of the outage is here. While there has been some of the usual […]
  • Microsoft can do it without partners
    Microsoft’s biggest strength has always its partner network and it seemed, at least for a couple of decades, that a strong channel was needed to get your product into the market. Few remember the days where buyers only saw products in computer magazines, computer trade shows and the salespeople walking through the door — the […]
  • The significance of Linux VMs on Windows Azure
    One of the most significant, highly anticipated, and worst kept secrets of the Windows Azure spring release is the inclusion of persistent VMs, with the notable addition of support for Linux on those VMs. The significance of the feature is not that high architecturally — after all, Windows Azure applications that were specifically architected for […]

@simonmunro

Follow

Get every new post delivered to your Inbox.