Crappy software. It’s everywhere. There is far more poorly-designed software than well-designed software. So much more, in fact, that we are literally drowning in crapware. It gives all of us in the software business a bad reputation. I hate it.
You’ll find lots of information on how to build better software (just click here). However, tools and techniques can only get you so far. If your company is serious about building the best software in its market segment, change your attitude. Here are a few suggestions.
- Lower the stress level. I know there are occasional needs to crank it up and push hard to get a project done. However, in some companies, every project is like that. It’s wrong. It generates waste, rework and paranoia. Lighten up. I’ll bet software quality improves and productivity increases too.
- Cut back on the meetings. Everyone seems to hate meetings and yet they are ubiquitous. Just stop! Cancel them! Move on! Having a meeting must not be your de facto approach to dealing with problems. Meetings should only be held when there is a clear and pressing need. Try walking down the hall and having a one-on-one conversation instead.
- Reduce the formality. Lighten up. Relax. Make every day, casual Friday. Even Steve Jobs wore jeans and a turtle neck. People should be able to speak freely. Having to carefully select every word and make every detail politically correct wastes time and stifles innovation.
- Don’t be a pointy-haired boss or a seagull manager. Managers and tech leads do not always know what’s best. That’s worth repeating — managers and tech leads do not always know what’s best! Assembling a collaborative team is the best way to determine the optimal solution to a problem.
- Make it fast. When developers have to wait for software to load or simple file copy operations to complete, their minds wonder. They’re more likely to pick up the smartphone and check Twitter and Facebook. Invest in high performance systems. They’re worth every penny. Then, identify and eliminate bottlenecks. See how much more gets done.
- Mix it up. Many companies like dedicated and highly-focused employees. I hope they also like high turnover because that’s what they’ll get. Cross-train and assemble multidisciplinary teams. Everyone will be more satisfied and productive.
- Offer developers multiple development environments and tools to choose from. Having everyone use identical configurations makes sense. They are easier to maintain and troubleshoot. But at what cost? Forcing developers to use tools they don’t like only slows them down and encourages them to find work-arounds. It’s not worth it. Embrace diversity.
- Upgrade. Some companies stay with what they know too long. They use a software package until they just can’t use it any more and are forced into upgrading. That’s dumb. Stay current. You don’t need to jump on every new release but you should upgrade at least once a year. (If the vendor isn’t producing new releases at least once a year, find another vendor!)
- Implement reasonable security constraints. Don’t lock down your environment so tightly that even simple tasks are hard to do. Implement my simple productivity rule; any group that mandates a new process or procedure that reduces productivity, must provide an offsetting productivity improvement. Let them wrestle with that mandate.
- Ask more open-ended questions. We all need to tell less and listen more. If you’re still wondering why your software is crap, go back to the top of this post and read it again.
photo credit: illuminaut via photopin cc
Congratulations, this is a great article. What I like about your points is that they do not focus on the teams productivity only. Better software does not solely require better developers. It is similarly crucial to manage the environment appropriately. This is definitely something where managers can add value, because they have a grip on levers which are hard to reach from within the teams – particularly in a silo-styled organization.
Agreed. Silos are a big problem and far too common in big orgs.
Great post, Vin! The emphasis on creating the conditions and environment that drive productivity versus “driving” productivity from the team is spot-on!
Comments are closed.