There is to much money in the field of IT. An industry full of sneaky little criminals, pretenders and scammers! All burning money. Lack of expertise from managers when buying services. Consultancy firms selling fictitious consultants for 1 Swedish krona. Employees and consultants wanting to expand their résumé with cool technology. Managers enforcing a development process. And developers spending time on building completely irrelevant solutions and doing so while knowing it's wrong. Or developers working in non optimal ways, knowing we are doing it wrong and could be delivering faster. All doing this without speaking up!
Even if you do not have a direct solution to a problem, Speak up! I'm pretty sure the one paying for the party would like to know if someone is feeling that their money is not being well spent.
Managers
We as developers are not in on this robbery alone. Not at all. Managers are also to be blamed. In general, we as developers want to do it right. We want to help out providing business value. We like to optimize and we like to deliver business value. As a manager, it's your responsibility to help us to help you.
Don't decide how we should work. Decide on what you want delivered.
Stop throwing development processes on us. Get us on the journey. Get us involved. Otherwise chances are high we will either give you 10% of our brain capacity and barely do the things you ask for. Without passion and love. Or more dangerously, we might start seeking technical challenges in the tasks, going bananas and start building artifacts that we find fun and exciting.
There are managers who do not act when they hear frustrated developers. Developers frustrated about the development process or developers frustrated about some technical decisions. Managers who quickly responds something like:
We can not change this so late in the project.
But can you afford to change it later on?
Is it less expensive to fix the issue once you are in production? You might be able to go for it. Perhaps time to market is more important. And sure, it might feel hard as you have invested lots of money in it. But learn from it. You have now evaluated one or more paths that has been found "not working". And if you stick to what you have. Then be sure the concerns raised by surrounding people will not blow up in your face when you eventually get into production (if you ever get to production that is).
I know you have to get out on the market and that perfection can not be achieved all the time. Nor should it. Just pay attention to people raising concerns. You are investing for the future. The product/system is being built, it's not being decommissioned. Chad Fowler talks/writes about that we are leaving a legacy behind. As in, legacy should be seen as a positive thing, also in software projects. A thought well worth to embrace.
There are also managers who know they are to inexperienced to determine what to expect from teams when it comes to pace and quality and naively let the work continue and thereby more money is spent on building wrong things and/or low quality solutions. Here's a tip for you:
Bring in an independent party who's role is to review what's being delivered and know what you as a customer should expect when it comes to pace and quality etc.
Developers - dare to shrug your shoulders
The pace of new technological solutions is rather high and we as developers can not know everything. To some extent we have to be allowed to learn as we go. New frameworks, languages etc. is rather easy to learn. We can read books, look at videos, take courses etc. It's something we are used to do. But when it comes to understanding the domain of a certain business. And identifying their business capabilities etc. That's an area where we aren't the experts. An area where we need assistant in. We need engagement from the business. In fact, we should crave engagement. Without it, the chances of delivering the right solution is greatly reduced and we will be burning money.
If you find your self in a position with to little engagement from the business. Stop "trying" to deliver. Solve the problem of getting business engaged first.
If you are in this situation and gets asked for when a delivery can be made. Shrug your shoulders. Make them understand that you have to little input and backup from them to solve the problem. Make them help you so you can help them.
Developers - dare to say no
As I said. We can not know everything, nor should we. But sometimes we should not even try to solve it. If we are faced with a problem, way out of our league, dare to say:
Hey, regarding task X. We can try, but we will most likely fail or it will take to long time. Bring in a specialist instead. One that really knows how to solve this particular problem. And will solve it within a few days and who then can educate the rest of us.
A good case could be: getting an effective integration & deployment process in place; Or implementing a known to work testing strategy. Most often I've seen the opposite. Consultants are brought in as pure resources. Peers to the employees. To be clear. That is OK. You might need to scale temporarily or there might not be any candidates to hire. Again, it's OK. But It's not OK to burn money by having them to learn everything and come up with a "barely" working solution when you can spend money on one specialist that both solves the problem and-also educates the team members.
What about innovation, freedom and fun?
Being a developer means you have a creative work and it's of course important to leave room for innovation, freedom and having fun. Absolutely! But if you start producing irrelevant artifacts just because it's fun, you are starting to get close to be burning money. I could be very boring and say something like: "the things that is not core domain and doesn't have an high impact on your competitive advantage, is not something you should spend money on.". But instead lets identify it like this:
The artifacts that aren't about the business, but instead things that we as developers find fun and interesting. Like building frameworks, tools and infrastructure and cool things for other developers. Those are good candidates for being irrelevant artifacts.
Many times, there's already an of the shelve solution for a particular problem. A product being built by other developers who are dedicated to be building the exact same thing you are trying to build. The difference is that they are supposed to do it. Are dedicated to be doing exactly that. It's their business and core domain. You on the other hand, is supposed to be contributing to providing the customer competitive advantage against their competitors. Well, are you?
To build or not to build - it's not a binary choice
Obviously there are cases when there are supportive domains and tools and frameworks that can be motivated to be built in-house. Just don't fall into the naive belief it's simple and easy. The first few releases are simple. But then what?
Like if you decide to take the route of building your own servicebus. It's "easy" to get the first few releases out. Unifying transports, formats, routing, messaging patterns etc. But it soon starts to become complex. Especially when you start looking at state and messaging guarantees.
Come on! It's fun! Please let me get to build that so that I can have it in my résumé.
Recognize it? Then be alarmed that you probably are heading down the wrong path. Also keep in mind, that the results of your custom made bits will most likely not be as good. Because the software you are buying, gets battle tested and have bugs reported by far more users than your homemade bits ever will. And it's not easy to compete with products being built by people who are dedicated to solve that particular problem.
Custom solutions and their secondary costs
If you decide on building these kind of core components yourself (e.g. a servicebus) you should also be aware of the consequences it might have on any surrounding teams.
There is a high chance that any dependent teams that are supposed to use the custom built components will suffer from continuous updates and breaking changes from the team writing them.
Until the product has been stabilized there will be interruptions in dependent teams. If you would have purchased an already finished and mature product, those teams could instead focus on how it's supposed to be used and integrated into their solutions. Instead of worrying about migrations between frequent breaking changes or unstable behavior in runtime, all as a result of using an unfinished product.
Who is responsible?
Who is to blame? The developer? The architect? The managers? The naive customer? In my opinion, it’s all who doesn’t speak up when feeling something is wrong. Transparency, openness and honesty are key components. Honor them and ensure blame has no place.
As a developer, I admit it's fun to be building infrastructure-, core-and/or framework components. I mean, I would rather wrestle with writing bits and pieces for other developers than to be working with enforcing business rules. But is it the correct thing to do?
It's important to remember that being a developer means having an occupation that is creative. We like to be challenged and solve problems. And I do believe that to get the most out of us developers, we must be allowed to have some degree of freedom. It's an act of balance. And to some degree the customer will have to take some unnecessary costs. Just remember, the line between investing money and burning money is very thin. Be transparent and open. Don't try to hide things.
We all should be focused on getting a streamlined process in place. A process allowing rapid and continuous deliveries and production feedback. Start small. Design cohesive components/services that are decoupled from each other. Honor the contracts and communication strategies between your components/services/teams. Focus on minimum-viable-products and get them out. And if you find friction. If you find areas where you can improve the process or increase the quality of the released solutions. Speak up.
Simple, right?
//Daniel
[post header image]: https://pixabay.com/en/euro-money-inflation-currency-2387086/