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.
2 comments:
Probably the point I agree with most, but the hardest for the client to accept is the "Developers provide their own tools". Personally, I don't ask the plumber to leave his tools in the truck and use the tools I inherited from my grandfather. I can't say what the best way to accomplish this with security and compliance issues, but it is huge when you can't bring tools to the table for getting the job done. Tools for code refactoring, project communication, database syncronization, profiling and a host of others. Without these, you nearly neuter the developer and force him to spent his time doing manually what the tools would do automatically.
However, your emphasis on trust and partnerships have a shortcoming. Here's the rub...the contractor comes in and puts in the "quick fix" to "save the day" because that's what get the client back to making money. Was it the "right fix"? Was it fully tested? Will it be maintainable?
Yeah...by the next guy.
Personally, I think the bigger thing is always to create the trust relationship. If you can get the client to trust that you have their best interest in mind they'll generally let you do what needs to be done. You must prove that everything you do is going to add value to what they are doing.
Keep in mind...consulting should never be about "experimenting" unless the client knows it ahead of time. I have always hated the consulting company that will try to make every consultant an "expert" at all technologies just to get them billable.
As a consultant, does your company expect/reward you for being one of the best or is it for being the most billable?
If I were your client, and I know you are driven by being billable, I will always be a bit skeptical that you are working your hardest to "get done and get out".
When was the last time your consulting company left a client not because they couldn't pay, but because the project was finished and they were happy with the work done?
When was the last time you told a client you weren't adding value to the project and it was time to shake hands and part ways? I have--and it gained the respect that would get me invited back.
I agree with the developers bringing their own tools. My father is a carpenter and he brings the best tools to get the job done. I've tried to bring my own tools and had to fight with the admins to let me hook-up to their network. Unless you don't need any resources they have, then no problem. Also, if you are turning over source code for them to maintain in-house, just make sure they can continue without your tool belt.
I've seen my share of duct-taped systems. It's what I like to call the V'ger Syndrome (from Star Trek). The systems have been pieced together to a point that they are monsters looking to "join with their creators". They are out of control. However, this leads into your point of Less Tech and More Domain... it's usually a cost factor. All you can do is point it out without insulting (or chuckling too loudly) and just add some more duct-tape and twisty-ties and move on. Actually, I’m working on two projects now that require me to go to the hardware store every day. It’s amazing anything runs at all.
Post a Comment