Why do you spend money on Software Development?
Why do you pay your employees and freelancers to develop software for you? Why do you spend money on training for them? Why do you pay external consultants to show you better ways of developing software? Just pause for a few seconds and think about it...
All the reasons you could think about will boil down to two big themes: You spend money on software development to earn money or to save money. Anything else would not make sense. You want a return on your investment.
Are you losing money right now?
You want your software development organization to be like a well oiled machine. A machine that turns ideas into running, user-valued software. A machine that can turn customer requests into features in a predictable way: Where you know when you'll get the result and which quality you can expect. And it seldom works this way. Maybe you can not predict the quality of your results correctly because every now and then, some defects escape into production. Those defects can be ridiculously expensive. When you create software for "the market", you might lose customers and referrals. But even when you create in-house software, somebody using your software will not be able to work as effectively as possible and your organization loses money. And then there's the cost of fixing the defect, creating a hotfix, ... Maybe there is a deeper root cause for those quality issues: Maybe the design and architecture of your software is not as good as it could be. Maybe it is just not suitable for the new requirements anymore. Or it slowly degraded because people did not care enough or did not have the time to constantly improve it. Whatever the reason, your not-as-good-as-possible architecture and design cost you money. Implementing features now takes longer than it used to. More defects escape into production. Cost estimates become less and less accurate. You might have an even bigger problem: Not all the features you work on provide a high value to the user. You implement something, and as soon as it is in production, change requests are coming in. Maybe your analysts did not understand the users correctly. Or your developers did not implement the feature correctly. Or the users did not even know exactly what they wanted - until they saw the first version. Nevertheless, you'll have to do re-work and this costs money. You probably also lose some money in the long chain of little things that have to happen for software to come to life. Your process for developing software might be too inflexible. Maybe some of the people involved are not communicating as effective as possible. Maybe you are producing too many artifacts that do not add value. Maybe it just takes very long until you get working software after a feature request.All teams struggle
So, did some of the above sound familiar to you? Don't worry, that's normal. All teams struggle with the issues I mentioned above. But the best teams have found ways to deal with those issues quickly and move on. And even the best teams have to work constantly on improving in handling those issues. And when some of the above sounded familiar to you, you now know where you can start to improve. But improvement does not come for free. So, is it worth investing money? What return on investment can you expect?Software is expensive
All right, everybody knows this. Software development is expensive. The salaries of the developers, office space, equipment, software licenses - This means that even a relatively small team can cost a high six figure amount per year. And there are probably more costs in your organization that are part of your development costs: Managers, HR, controlling, ... all work (partly) for your software development organization. So the real cost of a small team is probably in the low seven figures per year. What if your developers understood only a little bit better what your users needed? You would produce more user valued functionality and spend less time on re-work. This means you could also produce customer valued features faster! What if only a little less defects would escape into production? You would spend less time finding and fixing defects, and you'd have more time to work on user valued things. Also, support would be cheaper. And your users would trust you more, recommend your software to others, and work more effectively. What if your software architecture and design allowed your developers to add new features in a quick and safe way? You would face less defects because developers could better judge the side effects of their actions. And the predictability of your output would improve considerably. So if you could improve only by a few percent, that's a few percent of seven figures per year: Still a lot of money!The problem with the blind spot
All right, let's start improving! You just have to pick some area and try to become better. Can you do this on your own? Maybe you can. But you'll face a serious impediment: Teams that have been working together for some time develop blind spots. After a while, you stop caring about small inefficiencies. You just live with them. You probably don't see all the little hand-offs and communication issues that happen within your team. And you don't care about all the things that seem to be outside of your control. I experienced this myself a couple of times. When I came to a new team, I often had lots of ideas for things we could try. But after working with a team full time for a year, very few new ideas came to my mind. I was too involved with the team - I had developed the same blind spots. On the other hand, I once came to a scrum team who had been working together for several years. Everything they did was routine. The held regular retrospectives, but only minor improvements came up. They thought there was not much left to improve. I was new and wanted to find out how they worked, so I asked a lot of questions about how they did things. And after some time, a very experienced developer said "Maybe we should find out why we do things the way we do, and if that's really the best way". From there we could start to change things and improve again. Sometimes you just need a little nudge. And sometimes somebody from the outside, who is not a part of your organization, can show you a perspective that you fail to see from the inside.How can I help you?
As a consultant: I can show you ways how to better understand what your users and customers need and to better capture that knowledge for your developers. You will know exactly what is needed and when development is done. You will spend more time on customer valued features and less time on re-work. I can work with your development teams to improve how they work together. There will be less communication problems and less busy-work. We will work on making it easier for your teams to work with other stakeholders - Users, operations, management, ... Everybody involved in creating software will spend more time working together and working with the rest of your organization. As a trainer: Your teams want to learn how to create better software and how to create software better? I can work with them on improving their development skills. I can show them how to create high quality software, deliver often and keep the architecture and design up to date. This will save you money in the long run because the pace and predictability of your software development organization will remain high. Down in the trenches: I can work with your teams on the code, adding features, adding tests, improving test quality, refactoring your code and improving your design. By doing this, I will help your team to improve your code and develop the software, and I will show them ways how they can do it on their own. I can help you save money by developing software more efficiently. And I can help you make money by better capturing what the user wants and delivering value earlier.Or:
Learn more about how working with me could look like.
My name is David Tanzer and I have been working as an independent software consultant since 2006. I help my clients to develop software right and to develop the right software as a trainer, coach and consultant. I speak at conferences (like W-JAX, Con-Fess, Droidcon, the DOAG conference, Herbstcampus and others) and write a blog about software development.