In 2004, I entered the profession of software development. Working in a small information technology department for a large company; half of my day was spent coding small applications to support our functions, and the other half was piecing hardware together to keep servers running. We actually reported to the accounting department because they depended on us the most. It was the Wild West.
In the years since I’ve worn many hats. Like my colleagues, I’ve experienced the highs and the lows of the profession. The rush of putting an application into production that elated customers. And, alternatively, working countless hours on code to find it fell flat. I’ve held leadership and servant leadership roles where I’ve butted heads with others in charge. Worked with and on development teams that have lost sleep over the fear of failure, and I learned the finer art of customer and stakeholder interaction.
These ups and downs, evened significantly for me when I began iteratively building software; both architecturally and with process. My coding tactics had to evolve, and so did my ability to interact with customers and stakeholders. I became in tune with the business direction, and software was getting to the customer more frequently and with higher quality. Working iteratively with more customer touch points allows for fewer surprises, less dread, and less disappointment. It did also cool the rush I felt getting software to production, but I accept that tradeoff over dissatisfied customers.
There is no doubt that we, the software development community, have come a long way since I’ve entered the profession. The tools we use to develop and deploy applications are significantly more robust, and most companies are working to become more efficient with their processes. I think I can safely say that very few software development departments report to accounting anymore because software has come to the forefront of everything we do.
Even though we’ve evolved significantly over the years, we as a community are still going through hardships. We can still have disappointed customers, sometimes low-quality products, data breaches, long delays in releases and other impediments. There is still much room to improve.
The Next Catalyst: Forming New Expectations
How do we look towards the future and rid ourselves of that disappointed feeling? How do we organize and deliver the next phase of improved products? In my mind, it comes down to expectations. We need to change expectations inside our world and the world around us. Software development is not an exact science where all inputs and outputs are explicitly known throughout development. There are many moving parts, conversations, and decisions being made across a large breadth of an organization as development ensues. If expectations are not aligned, and transparency is lacking, then we risk having that disappointed feeling again.
If software development continues evolving as it has over the past 15 years. If we’re truly innovating and driving for efficiency, then I believe the following is what the future will look like:
Business and Information Technology divisions stop trying to get along because they no longer have to.
In many corporations I’ve been in, there is a strict divide between business units and information technology leaving expectations up to an intermediary force. I picture a future