I've been doing the software consulting circuit for a while, although not too long - about 2 years. It's enough time to know that there's a lot of room for improvement, and I'm going to discuss in this blog post what trends I think will emerge as the industry matures. Many of the points I'm going to make are based on observations I've made about software quality, and how organizations will begin to value it more.
More Emphasis On Partnerships and Trust
Too many projects end in something less than success. It's time that we change perspectives on software development and become fanatical about achieving our customer's goals. What I think this means is that we completely change our business models. Instead of the old-school fixed bid or time and materials contracts, let's go for more of the incentive based contracts. In other words, I get paid when I've made you money. Doesn't that take a huge amount of trust? Yeah it does, and that's where I think we need to get. (You can do some more reading on "Agile Contracts" here.)
Incentive based contracts encourage a healthy economy between partners. There's only one goal: to make each-other successful. Now when I come to my partner and ask if it is acceptable to take care of some technical debt, or begin using Test Driven Development, he/she will know that I am only doing it because it is a true investment - and I know that it will benefit me (us!) in the future.
Less Emphasis On Methodologies
Agile, Scrum, XP, Waterfall - they all have one thing in common: they don't mean the same thing to any two people. It's all about communication. We have got to stop applying tools to the process by default and instead have one goal in mind: Keep Improving. I think we'll see companies start to understand that in order to manage a software team you have to let the software team do the managing. There are no better people to make management decisions other than your team. They're on the front-lines with the most comprehensive knowledge available, and will always make the best decision possible.
Teams will still require leadership, but leadership should begin to lean more and more on their people to do the critical thinking and solve not only software problems, but also process problems. In summary: More thinking, less blindly applying tools and/or process.
More Value Placed In Established Software Teams
It sounds reasonable to believe that a developer is a developer is a developer. You always hear how everyone is replaceable and we're just all cogs in the wheel. I'd argue that, however. Developers who have built relationships, established trust, and learned strengths and weaknesses will outperform any other team that has been banded together on-the-fly. Managers and decision makers will eventually begin to see this as they make decisions on who will build their software. Thus you'll see more software teams grow and strengthen and their services will become more valuable.
Single Responsibility Teams Will Fade
As people mature in their careers as software developers, skill sets will mature to the point where it will become expected that feature development will occur in a vertical fashion. By this, I mean that each developer on a team should be able to construct a software feature from top (UI) to bottom (Database) with minimal intervention from other developers. There will always be developers with talents that weigh more on user interface design versus skill in SQL Server (for instance), and they will be valuable as team members. But, every team member should have the ability to work independently to provide value to the paying customer.
Developers Will Provide Their Own Tools
I've come onto a customer's site on a staff aug contract to be seated at a computer that my mother would have grown frustrated with after using a word processor. This is an edge case for sure, but hopefully it illustrates that our clients don't always understand the need for quality tools. I don't blame them - it's not their area of expertise. We are brought in to fill a need, and we know the most about what we require - so we should be the ones to provide the tools necessary to do the job. There are other trades that require their craftsmen to provide their own tools, take for instance mechanics or construction workers.
Less Emphasis On Technology, More On the Domain
We know this: software does not fail to meet customer expectations because of technology. Our first goal shouldn't be to start writing code, but to understand the domain and help our customer make more money. We should be looking at their model and suggesting improvement points. We should be more than the geeks who write code, we should be looked at to solve challenges - technical or otherwise.
Less Staff Augmentation Consulting
In a couple of companies that I've consulted for on a staff-aug basis I've seen software systems that were almost literally being held together by duct-tape and paper mache. The observation I made was that the company was hiring contractors almost exclusively and that these hard working people would swoop in, get a cursory understanding of the system, and make patchwork fixes. These fixes were always just good enough to get the system operational again. And that is probably noble of them because everyone knows that in order to prove you're worth your salt is to be the hero and save the day. This model has got to end.
