Each paragraph here deserves its own chapter, and one day maybe I will allocate enough of my time to do just that. For now, I'm putting it out there in a shorter form, just to help readers realize what all needs to be improved in the software development industry.
I'm a software architect and developer. What I wrote below is how software is built today.
I'm trying to fix it for people, teams, and organizations. This is what I do for living. I do this either by either working on complex and challenging software projects or by providing training courses around various topics of software development and software architecture.
If you are a developer and you recognize yourself below, please take it calmly. I'm not trying to criticize you. I'm trying to raise awareness and hopefully, positively affect behavior of every developer out there. I'm trying to make world better.
I'm still amazed how many companies are ready to pay salary to developers who consider bugs in software a normal thing.
I consider every bug an unfortunate mistake, and I take them seriously. They are waste of money, time, and patience.
If a developer says bugs are normal to be found in software she writes, then be prepared to have bugs in the software she gives to you. Good luck!
This relates to all kinds of tests. Anything that asserts quality of the product that a developer delivers, is considered not the developer's job. That's how much developers care about what they put in front of customers.
Developers don't like writing unit tests.
Developers don't like writing acceptance tests.
Developers don't like writing functional tests (they put this responsibility on Testers).
Most developers don't even know what TDD or BDD means.
Some developers don't even run an application after they wrote code and before they pass it to testers.
I have witnessed a developer asking a product owner to make a choice between a feature delivered fast without unit tests, or with unit tests but much later.
What do you think a product owner, a non technical person, would choose? of course feature delivered faster was the favorite.
But why whould any normal developer present such a choice to non-developers? why would any developer consider doing a bad job just because somebody does not understand the consequences?
When developers see a bad code which is just 2 lines away from where they are looking at right now, they don't bother to clean it up. They don't bother fixing something if they see it's not right.
Some developers like their own code so much that they forbid others touching it. Code they wrote, no matter how bad it can become, is a history forever.
I personally don't care about "my" code. Please fix it if I missed anything. I know you have good intentions for the software if you do so. That's all that matters.
If you don't refactor somebody else's or your own code when you see that it needs improvement, you are adding to the debt.
Nobody will come to pay back the debt if you are not doing it yourself. Or are you smarter than others?
One day, you will slow down with the heavy weight of the debt that you have accumulated.
When the deadline approaches, a developer understands that the delivery is impossible. Project manager demands work to be delivered on time no matter what. Finally, developer agrees and decides to do a quick and dirty job just to meet the deadline.
Most of the developers cannot say No instead of compromising quality.
I think there must be some self confidence and transparency to avoid such problems. Explanation requires cultural shift and won't fit on a page or two.
Software can be complex from inside, but it should be simple to maintain and run without developers around.
That's how developers should understand "Simplicity is the ultimate sophistication".
However, developers want to use simplest skills possible, without any knowledge of advanced design techniques, and they want to build a mission critical software. They think simplicity means - no skills needed. But simplicity means - to hide complexity.
A person without skills cannot say a phrase in a concise and short form. Anybody can explain a meaning of an apple using 100 words. Only a skilled person can be short and concise.
Development teams are kept apart from CI/CD processes. They don't know how to build, integrate, deploy, run, and maintain their application in production environment.
If they don't know all these important steps, then they have no idea how to make them better. That's why there are so many problems in all those areas and nobody can say confidently how to fix them.
Development teams should own both development and running of the application. "You built it - you run it".
Many developers and architects will claim that they are following TDD, BDD, DDD, and many other buzzwords. You wouldn't even think that they have learned these words just to participate in "fancy" conversations or to pass interviews.
Many software architects can describe nice design patterns, approaches, and standards. It's all on the whiteboard and it all looks so amazing.
Then you open the codebase that the development team wrote based on the bright ideas of those architects.
Codebase is spaghetti, dirty, nothing like what was advertised by the architect. You realize there is a disconnect.
Either architect cannot explain things properly to developers, or cannot demonstrate how to do it right, or cannot read code.
Either way, such architects exist for whatever reason and they are still called Architects.
This is used as an excuse too, to let it be the way it is now.
Problems won't be solved by themselves. If you really want to change things, just do it.
Find right people. Give them right power. Let them execute. Keep them accountable for results.
A single person with the right attitude can change an organization consisting of couple of hundreds of developers (taken from my experience). This is absolutely doable.
Software developers and architects create software that is buggy, hard to maintain, and hard to deploy to production environments.
Those same software developers spend enormous amount of time and company's money to fix bugs, to maintain the running software, and to deploy it to production environments.
These people are paid and even awarded to solve problems that they create themselves.
There are other [very few] developers and architects who don't work this way. They do their best to avoid bugs, to make maintenance unnoticeable, and production deployments a "no big deal".
These people don't fix bugs, they don't teach you how to maintain software, they don't dedicate their nights to production releases.
These people don't receive awards for preventing problems.
I've attended meetings initiated by management, where they gather "bright minds" of the organization to solve the problem that has become unbearable.
Wait... but those exact people created the problem in the first place.
They cannot solve the problem, because they are part of the problem.
Software architect or developer is only as good as the software that she has created.
You are asking wrong people for solution.
If you have such developers, ask them why they built the wall that cannot stand by itself.
Would you live in a house like that?
There are only 4 cornerstones in software development: time, scope, budget, and quality.
Many times, people don't want to compromise any of the first 3 things, so guess what is left to compromise (quality). Then they complain that the software does not do what it's supposed to do.
Recruiting agencies have margins, big margins. Recruiters will not even present a talented consultant to the company if the consultant's rate is going to eat their margin. They won't cut down their margin even if it benefits the company that's in need of the top notch talent.
Recruiting agencies don't really care about their client's success if it goes against their financial goals or policies.
But they are still recruited and paid equally.
When I was full time, I had to deal with paperwork, annual performance reviews, compliance trainings, complaints of developers who could not stand criticism for their work... I had to deal with much more.
I was full time with Dell, and I quit. I felt I could do more good for software development industry by being a consultant.
I consider full time employment a burden, which comes with a lot of needless baggage, dirty politics, careerists who don't care about software, and people who don't like their jobs but have to keep doing it for various reasons.
I was once interviewed by a developer who questioned the correctness of every answer I gave. I didn't pass that interview.
In a couple of weeks, I was interviewed by another engineer with very strong reputation, who found talking to me very educating for him and note down things that he didn't know before talking to me. I passed that interview.
First developer was junior, and he won't be able to properly assess anybody who has better skills that he does.
Yes, this is unbelievable, but it's very common.
I personally was interviewing a lady over Skype. She pretended to be speaking. Somebody else was answering my questions, while she was just moving her lips after the voice. When I accused her for faking the interview, the call was ended and I was never able to reach her again, either through Skype or through the recruiter who provided her resume.
I've heard and seen other similar cases too.
Always interview your candidates either in person or over video conference!
Author of the above content is Tengiz Tutisani - owner and technical leader at tutisani.com.
If you agree with the provided thoughts and want to make it part of your team's culture, we can help.
We provide in-person, immersive technical workshop training courses around Software Architecture, Domain-Driven Design, and Extreme Programming topics. We also develop software solutions.