This map proves one thing, racism is caused by living in warmer climates.
Because Low Volume + Low Margins = Huge Profits !
“Gandalf and Bilbo Go Space Trekking”
As a software developer, you are primarily getting paid to turn your expertise into functionality. No one cares how many lines of code you churn out, they care whether or not you are creating something valuable. They care that the features you create somehow make the business more profitable.
How do you create features that have a high value to the business?
This continues to be one of the biggest problems in software today. In some software businesses assessing the value of a feature can simply mean evaluating how the businesses financials have changed, but more often the feature has an indirect effect on the financial metrics.
Many times the software is used to help others do their jobs better and in many cases a feature is added to increase user satisfaction. The audience and purpose of these features makes them difficult to measure.
All this to say, it’s important for developers to realize that although the work you do is highly valuable, it’s really hard to measure and understand, and even more difficult to prove. Developers of the 21st century need to have a good understanding of the business, need to be the pioneer of measuring the effectiveness of the features they create, and need to be able to communicate with “business people”.
In the past software developers have struggled to integrate their expertise into the larger business. They have struggled to interface with non-technical people and have especially struggled to communicate the limitations of what the software can do and how best the software can help the business.
This type of severe lack of communication has necessitated many types of fixes: project managers, excessive meetings, agile software methodologies of all kinds, and a myriad of other ideas. The software industry as whole has actually gotten decent at implementing agile and providing a fairly decent communication framework between software and the business.
Now it’s time for the next step, it’s time for software developers to recognize their role in making business decisions. Anytime you make a decision about your software you are also making a business decision . You are making a decision about resources, schedules, what the users experience will be etc.
If you have developed a decent amount of software were features are defined by business folks, sales, or anyone non-technical you have experienced a pattern of absurd uninformed decision making. Something like the customer asked for X, to solve Y, by date Z. Where X doesn’t solve Y and could never be accomplished by Z. Then you go ahead and implement X, and everyone is pissed because you did what they asked you to do.
This is at best a highly flawed dynamic, but it persists anyway, and for a variety of reasons we don’t need to discuss here.
However I will propose one solution. The software developer/team needs to be authoritative and trusted with business decisions. Do to that we need tools.
Collection of metrics is a great tool to start with. If we are able to make a quantitative measure of the features we are designing then we have a great start in understanding the usefulness, flaws, and value that a feature provides. Let me write that in bold, A GREAT START. Metrics are not the beginning, the end, or the holy grail of anything. There is so much that a metric can’t tell you.
But there are very useful things metrics can tell you. Metrics can tell you how often a feature is being used (did someone click on this thing), the level of engagement (are people coming back to this), demographics, and a whole bunch of other interesting stuff.
Metrics will not make you an authority in your business, they are tool that will help you craft the narrative around the value of a feature and it’s cost. A tool that will take you from anecdotal examples into a more concrete realm. They will help you layout out causes and effects so that you can allow the “decision makers” to choose the best options.
As a developer it is definitely your job to write code, but it’s not enough to crank out features. There are a variety of tools and techniques that can make you more informed about the costs and benefits of creating applications and features, unfortunately there is no silver bullet. There are best practices and great suggestions like metrics, agile, user testing, etc. But you will have to find the right mix of techniques, tools, and art to be a truly valuable contributor to the business understanding of your work.
You have to be an arbiter of decision making and an expert in the business value of the applications/features you develop. You need to be able to make smart business decisions with the software you are writing, and then be able to communicate that decision to the rest of the business. You need to be a well qualified consultant for your stakeholders so that they can make correct and reasonable requests that result in valuable features.