(Original creator: bolarotibi)

Guest contributor, Bola Rotibi from analyst firm Creative Intellect Consulting

Acquiring the very best development talent goes beyond having the best code developer. What skills should underpin this broadly applied term and how should one go about supporting the creative process of development

Read part 1 of this series here

Read part 2 of this series here

Read part 3 of this series here

Lest we forget…software’s success is not all about the code

Acquiring the very best talent goes beyond having the best code developer. Successful software is not just about the code: great coding in a poorly conceived and marketed product will be less successful than a great idea that is adequately coded, delivers the right experience and is well marketed. Oddly, this may not always seem that obvious to those outside of the software industry. So, if successful software is not all about the code, then what is it about and why are developers still such a focal point? – celebrated by some and damned by others. For many of those not fully cognizant of what the software application delivery and lifecycle management process entails, the developer presents a recognizable and visible central role in the building of software applications. Steve O’Grady’s very well written and insightful book “The New Kingmakers” makes a very good case of the market worth and value that a skilled and experienced developer or development unit can have. Developers or the development team can be influential and vital, especially if you are a software vendor looking to bring a software product successfully to market, and for it to have the right impact. But there can be a limit to their powers when part of an internal enterprise IT organization. According to a survey we ran on the state of secure Application Lifecycle Management in 2010, 2011 and 2012, code development was viewed as the most susceptible for security bugs and issues. Yet the same survey results indicated that developers have limited influence in the organization when it comes to ownership or making improvements to the security process. So whilst they are positioned to get the blame for problems, they have limited powers to make changes to the process to avoid those problems in the first place. That said, developers can kill the use of a tool if they don’t feel it works for them.

Important cogs inside a vital engine

Good developers and development are an important factor when it comes to software success, but they cannot lay claim to the star role in isolation. No one group or role can do so. The way an application is architected, the operational set up, the choice of platforms, tools and even methodology, all impact on the way the code is written. But more to the point, other factors contribute to the overall success of a software solution: factors such as the way that requirements are extracted and understood, along with knowing well the pain that is being solved and the experience delivered. The transition from development to deployment, and the test and quality processes employed, all have an impact. Furthermore, clarity of the value on offer, with an ability to articulate this and engage with all relevant audiences well, and the collaborative integrity of the lifecycle process, also add considerable weight. Despite this, we still resort to placing the developer at the heart of the operations: directing praise to them when it all goes right and delivering scorn and derision when it all goes wrong.

All for one and one for all

I for one am not detracting from the important role that software developers provide. As I have argued, developers certainly make for an easy target when looking to castigate or applaud the outcome of a delivered software solution. Whilst they are not without influence, other roles, skills, and process criteria that are often invisible (particularly to the software owner or end user client) prevail on the ultimate success of a software application or product: No matter if it is delivered internally within an organization or externally to the market. Ultimately, developers have a lot more to think about and cope with. But then the term developer covers a broad range of skill sets, so there are multiple ways to specialize. Development today speaks to a broader remit that sees user experience, data analysis, design and mobile knowledge all join the skill set of the development team. There is an onus on the leaders of the IT organizations and the development team to recognize and support the evolutionary requirements and give the development team the resources that it needs to grow. There also needs to be clear recognition that not all individuals are cut out for embracing all the different skills required to taking on a hybrid role. I have longed argued that not every developer is capable of being a designer or an interaction specialist and vice a versa which is why we have some pretty rubbish applications and website still in circulation today. Nor is all development the same. For some situations, there is still the need for a developer that is singularly focused on quality code production. There is also a lot to be said for promoting a start-up mentality to your software development projects. Allowing developers and development teams to collectively consider the value being delivered will enable them to keep focused on the overall goals of the project and not get side tracked. In the melting pot of skill characteristics, perhaps one of the most important evolutionary traits to ensure enduring success is the ability for developers and the development teams to be open minded. But also to collaborate, communicate, co-operate well with their peers and see things from the perspective of the customer and the wider product or business goals. None of this is new, but it’s amazing how it is all too easily overlooked or forgotten.

This page has no comments.