Developers, software engineers, smart people, people have needs, these needs differ and certainly differ in weighting from person to person but I think the below lists the key desires of most. I, of course, can’t speak for everyone, I would however, like to be as complete and thorough as I can—I’m a techy, it goes with the territory—so please contact me if I’ve missed anything. Whilst this post is focused on software engineers it could equally apply to any profession that needs brains and experience.

I believe strongly that software engineering is a creative process. Not only is it a creative process like painting, making a photograph, giving a speech or product design it also requires large amounts of technical expertise. That’s it’s, an inate gift and hard earned knowledge and then, if that weren’t enough, determination to be successful and with the right environment: successful with others. These people are therefore incredibly hard to find, these are the people that will change the world.

People like these, people like you, can change the world, people like you have changed it, it’s sappy, I’m sappy, I won’t appologise. Below are some notes for your prospective employeers, custodians of your working life whilst you let them, I hope I can make a reasonable job of it.

Respect them

It pains me that I have to even say this: engineers deserve respect, they do a extremely mentally challenging job and the good ones, they’re smart, damn smart. When you treat them like children by taking away decision making power, coating their days in pointless process due to lack of trust or, worse of all, not listening to them then you do everyone a disservice. You won’t get even a tiny fraction of the benefit you could get out of them.

“Imagine what you’ll enable people to achieve if you believe in them”. \ — Dan North

So do it, believe in your people, let them know by showing them respect.

Listen to them

Listen to software engineers, they have opinions not just on software engineering but on everything from product developement, through personnel and on through P&L, they may not be right all the time but if they are as smart as you want them to be then they’re going to be right a whole, at a minimum they’ll give you new angles. Listening is the foundation of respect.

Other developers like them

Software engineering is a team exercise, of course from time to time we need alone time to think, but most of the time bouncing ideas of like minded people is going to be the best course of action. Be it pair programming, whiteboarding new ideas or discussing the latest technology over lunch, great software engineers like to spend time with other great software engineers, it makes them happy—fundamentally happy.

Remember software engineers, especially open source developer are ahead of most in terms of interacting online and therefore being part of a team doesn’t need to mean physical proximity, it could be via hangouts, hipchat or even good old IRC.

Fundamentally they want to work with other smart people with a common purpose, best make that common purpose yours.

Other smart people

Great developers want to work with smart people in other disaplines too. This could be product development, sales, marketing, procurement or personnel. It helps everyone grow, so unless you are running a production line (and why wouldn’t you automate that?), then make sure you only hire the best people throughout your organisation. Perhaps I’m stating something obvious: hire smart people—what I mean is hiring is the most important thing you do.

Access to tech conferences

Even when you get the best engineers working together in a team, with the best professionals in other disaplines, the knowledge and thinking can get a little stale. Engineers, we like to get out and meet other likeminded souls who haven’t been our team mates for years. Some of us even like to speak at conferences (cough), firstly because it feels good to share information, be part of something bigger and secondly it’s because it provokes a conversation. Let your gals and guys out once in a while, pay the airfare, put them up somewhere nice and let them meet other smart people.

Companies that talk about their (cool) technology.

This goes hand in hand with the conference attending, if you speak about the great things you are doing then people are going to want to come and work on them. Smart people want difficult challenges and they want to solve them in smart ways and then they want to brag about it. Smart people who want to do this and can’t are on the constant look out for those that will let them.

One word of caution, if you technology isn’t great you’ll do more damage than good try to palm it off as good. Either be honest and speak to the challenges or don’t bother.

Freedom to express their views

The best engineers tend to be opinionated (the reverse doesn’t necessarily apply) and so by definition they like to put forth their opinions. If you restrict them from doing so you’ll firstly make them sad and secondly deny them the chance of being challenged and finding out there was more to learn (there always is). Also be prepared for this taking multiple forms, for some this could be a posting on a message board, other it might be an empassioned monologue during a meeting but best of all it might be a commit to github.

Open source

If your software is closed then it makes it very hard for your software developers to engage with the outside world of software engineering in a meaningful way. It also takes away their ability to show off what they’ve been doing. Smart people like to show other smart people how smart they are from time to time. They do it a little for their ego but mostly to start a conversation with other smart people and learn.

By putting your software out there you’ll show the world that your company is made of smart people too and you’ll capture their attention, perhaps they’ll help you write your software, perhaps they’ll become a colleague (perhaps they’ll be your boss [ssshhh]).

Hardware & software they need/want

I’ve lots count of the times I’ve heard engineers lamenting being fobbed of when asking for better equipment. The logic goes something like, we have a standard build, it will only work on this configuration and it’s good enough for the guys in legal (no offense) so suck it up (of course most budget holders will put it more nicely than that but the engineers will hear ‘we don’t value you’).

Just stop it, let your software engineers pick any laptop, desktop, mobile phone or flux capacitor they want and as long as it doesn’t cost the price of a new family car every year, go with it. It will make them more productive, happier and ultimately it’ll save you money in time spent discussing it—don’t believe me, want a business case, tough, you won’t get the best techs to work for you if you don’t.

Safe environment for innovation

Everyone should be allowed to innovate, it shouldn’t be scheduled and it shouldn’t be the sole perview of a few chosen individuals, if you want to spend time looking into Huffman Coding and using it to increase data read times from disk then that’s what you should do—who else but the smart person thinking about that problem is going to have a better opinion of whether it’s a waste of time or not? Bear in mind it might not be her ‘job’ to be worrying about data density read speeds, go with it, what’s the worst that could happen?

A career path

It’s no longer good enough to force your best engineers to be people managers once they hit a certain pay grade, a few might want to, let them, but most won’t: so stop it. Give them something else to aim for that gives similar benefits: reward package, pension, car, bonus, blah. What else is there to aim for you might wonder, if it not a big team and a huge budget? It’s probably access to hard problems, large amounts of hardware, time and people but, you know, ask them, they’ll tell you.

Minimal politics

Normal people dislike office politics, engineers dislike them even more, make sure you have an office that is focussed on your purpose not playing silly beggars; enough said.

Minimal process

Have the absolute bare minimum of process that makes you feel comfortable, see how it feels and then remove some more, after about 10 iterations of this your probably where you need to be. The more process you have the harder it is to change and technology is all about change, therefore the more process you have the less likely it is that you’ll have great technology.

Meaningful appraisals

Appraisals are mostly theatre, make what happens useful and remove the rest. Make sure that someone that understands what the individual does leads the appraisal and don’t leave it more than a week to give positive or negative feedback. As a great boss of mine once said, appraisals shouldn’t be a 6 monthly surprise. There are entire libraries of books on this subject but that’s about the size of it. Everyone wants to know, objectively, how they’re performing, even or perhaps especially the best performers suffer from imposter syndrome, so let them know they’re doing a great job and don’t make them fill in a 10 page form every 6 months.

A company with a purpose

The worst possible thing is to have no meaning. A recent article talked of gifted people being plagued by feelings of meaningless, more than those less able. If your organisation has no common purpose then talented people are going to feel it more keenly. Have one goal, communicate it, then communicate it again, when it doesn’t happen, ask why, make changes, involve your engineers and keep communicating it. Did I mention you need to communicate your common purpose? What is it? Write it down, write it on the wall in spray paint, write it on every wall. If that purpose doesn’t interest them, shake hands and move on, if it does you can guarantee they’ll be fired up to know that everyone cares and that you care.

One of the oldest project management concepts I can remember being told about is the project management triangle. Whilst the project management triangle is largely misleading and quite frankly dangerous if taken literally it does at least tell you one thing: there are trade-offs in any given endeavour. For the classic project management triangle the trade-offs are three things with quality overlaid in a clumsy way. Those things are: cost, scope and time.

The theory is:

• If you have enough time and money you can deliver your scope
• If you have enough time but not enough money then you’ll have to deliver less scope
• If you don’t have enough time but enough money then you’ll also have to deliver less scope
• If you don’t have enough time and money then you are doubly in trouble and likely won’t deliver much of anything

Of course this is a very naïve way of looking at things and won’t get you very far. It doesn’t take into account things like morale, motivation, team politics, shared purpose, force majeure, health, ethics, sickness, personal life, indecision, competitor disruption and all those things that make humans and business such wonderfully complex and interesting things.

The triangle, as I’ve mentioned, has quality as its background, meaning I suppose, you can sacrifice quality to claw back time, costs and/or scope. Think about this though, can you really? Perhaps you can in the short term, how about the long term? If my team and I produce shoddy code that’s hard to read, has scattered concerns and global knots and all those bad things, then how am I going to keep delivering to functionality, at pace and within reasonable costs? This seems obvious, however it is missed or ignored remarkably often in small and large organisations alike.

The point is that if you sacrifice quality for short-term delivery of scope or to keep costs down then it will cost you more or you’ll get less in the future. Moreover it will cost more, take longer and deliver less for every subsequent project on that system. Until you’ve improved the quality back to an acceptable level you’ll be paying for that quick or cheap delivery in opportunity cost. Worst of all at a certain quality point the quality deteriorates faster and faster - interest is accuring on that technical debt.

Technical Debt

Ward Cunningham coined the term technical debt to describe this and like real financial debt it isn’t always desirable to avoid it. Just like in business taking on some debt can be a good thing, it can allow you to grow your business faster than otherwise and pay it back before the interest mounts. The same is true of technical debt. However, just like financial debt, if you keep on taking out loans and not paying back any of your debt the interest mounts and eventually the insolvency officers move in and shuts you down.

In software terms the insolvency will manifest in a number of different ways, technical bankruptcy looks like:

• Every time you introduce a new feature another feature breaks (sometime referred to as the whac-a-mole problem)
• Many of your best people leaving because they cannot take pride in what they are building (usually you end up with a churn of short-term contractors before eventually that costs too much to justify)
• A competitor out pacing you and taking your customers

What we have to do is look at the reasons for poor decision making and ensure we can avoid them. Why do organisations, decision makers ignore software quality and therefore long term growth to pursue short term goals?

Financial Cycles

Most companies run their finances monthly and then annually, there is nothing else that matters to some people than the end of period figures. If you’ve ever spoken to an accountant at the end of the month they are usually a jibbering wreck from burning the midnight oil and if you speak to them during end of year you can forget any chances of getting some sense out of them. Not that the accountants are to blame they are just the messengers.

This is because the books have to be closed, the results have to be calculated and everyone wants them to look as good as possible to investors, bosses, themselves or whoever. What this creates is a sprint for the line at the end of each period. What happens when you sprint for the line? You give it everything you’ve got, abandon all strategy and then collapse in a heap once the line is passed.

In software quality terms this is a disaster. It means that everyone burns the midnight oil, shortcuts are taken to get features in, testing slips and shortcuts are taken. When all is said and done a few targets might have been reached but actually the code is now a steaming heap of rubbish.

Hidden Cost

In order to really understand software quality you have to really understand software, this means understanding many complex things like: systems design, software design, at least a few programming languages, data design and so one, who understand these things? Not many people, that’s who, and these people are busy creating new software and not explaining the implication of poor quality software in a language business types will understand. Typical those people, as bright as they are, aren’t the best a translating software quality issues in to monetary figures.

It’s by the nature of the complexity of the problem that few people understand its implication and often not the people (trying) to count the costs.

Opportunity Cost

This is a huge hidden cost and as such is called out separately. Opportunity cost is the difference between the value of the selected approach and the best alternative. In simple terms if I select an approach that makes me £100 over one that would have made me £250 then I have an opportunity cost of £150.

It’s an interesting concept and it applies to software in the following way. Let’s for example say I want to add a cool new feature to a mobile app. It costs £1000 to write the code to do it one way (code change A) and £3000 to write the code a better way (code change B). The first reaction is to pick A. However code change A will increase support costs by £250 a month. Moreover it will make the cost of doing the next change £1000 more expensive.

Now the opportunity cost is £250 after the 5th month and growing every month. Moreover it might mean that the next change doesn’t get made because it’s too expensive or worst still it is done in a suboptimal way meaning that it too increases opportunity cost compounding the problem.

Transient Team

A stable team is key to keeping a good quality software product. If you know you are going to be looking after the software in 3 years’ or 5 years’ time you are going to have a lot more invested in making sure it works and that it is a pleasure to support than someone who’s going to be off at another company or client in 3 months’ time.

Don’t get me wrong, I’ve worked with some amazing and dedicated people who’ve came and gone from teams quickly for whatever reason, however, on the whole, the tension isn’t there to think long term.

Unengaged Team

Things get to a point where design decisions have been overridden so many times to meet short term goals that the team stop fighting it. When this happens it’s a sad thing, you have an unengaged team who can’t take pride in their work and aren’t delivering the value they are capable of.

Reward Schemes

Similar to financial cycles more often than not companies will award bonuses annually for meeting certain goals. Getting a certain number of features added or perhaps getting X million sign ups or shifting Y million licenses. This triggers the target fixation mentality, where anything and everything is done to get these things achieved no matter the debt and damage incurred to the quality of the software.

Additionally next year’s bonuses will be negotiated from the point of knowledge of the software at the end of this year. Highly debt laden system will have the bonus hunter negotiating for lower barrier goals. If they don’t get them they move on and someone else moves in and does the same anyway.

Some Solutions

Listen to the Experts

There are no easy solutions in this, however things that help are a voice for the people who understand the complexity of good software. Listen to you developers, listen to the designers and architects. You’ve hired them for their expertise so use it.

Help Them Explain

Accept that the technologist might not be able to put a financial figure on the costs, help them with that, come up with mechanism that works for both the technologists and the accountants, make balanced decisions based on the circumstances. Remember the best software solution might not always be the best decision for the company but it quite often is.

Manage Your Tech Debt Like Any Other

Have technical debt reduction as a metric that is rewarded equally or more than adding features.

Start to show technical debt on your P&L report, take it seriously because it is a very real thing that has brought down more companies than we’ll ever know.

Set Long Term Goals

Have bonuses rewarded over 3 years too, supplement annual bonuses with some longer term goals around software quality.

Stabilise Teams

Value a stable team over transient teams, do everything you can to keep the loyal people loyal and support them in their quest for long term software quality.

Summary

Software quality is incredibly important, it’s the long terms viability of any technology focused company. Without it you are entering a downward spiral to technical insolvency. Take it seriously, sure, don’t be frightened to add a little technical debt now and then, but do it consciously, record it and pay it back in a prudent manner.