Trust Me I’m A Software Developer

I’ve been thinking about this for a long time. When I read The Churn by Uncle Bob Martin I started questioning if what he stated was the real problem we have in our profession. I started thinking about my career and that of other people I know and realized that there’s another problem we face every day: we build invisible artifacts.

I Was A Crappy Coder

When I started programming I was a crappy coder. Yes, I was able to build what needed to be built and most of the times it worked… sort of… but with every new version I released also some bugs. As the software grew, developing new functionality became harder and harder and I was always behind schedule. It was stressful. I thought that was the nature of software development and accepted it blindly.

As years went by the pile of crap built by my team grew. Sometimes we started all over again hoping that this time we would do things better. Of course that didn’t happen.

We were a small team and I didn’t have any good senior developer as a reference, someone to teach me good practices, someone who would review my code or pair with me for a while.

The Revelation

Then, during a business trip, I met a Brazilian guy that introduced me to Agile and all the practices that helped you design and build good maintainable software.

It was an eye opener. We talked for hours about software development, sometimes until midnight and when I got back home I started studying. I began with basic things like how to choose good names and method and class extraction to improve readability and maintainability. Later I moved to concepts like automated test and why you should test your software in isolation, then TDD and pair programming and so on and so forth.

I started noticing bad practices and tried to get my coworkers involved in adopting better ones. Some of them accepted the challenge and started developing a sense for what good software was, others simply refused to even try.

Unit Tests are useless because you would never be able to cover all cases

ex-colleague of mine

Obviously things didn’t improve much, we didn’t have time for that. Pushing practices bottom up was difficult, my managers where blind and didn’t get that “just make it work” isn’t enough. I put a lot of effort into trying to improve the project I was assigned to, you know, to make my life easier and learn by doing, but all was done without asking permission because no-one cared, I was the only guy in charge of maintaining that project anyway.

I changed jobs hoping for the best, and I got something somewhat better. They didn’t had the best software culture I could hope for, but I had a lot of young colleagues who where eager to try new things and discuss about software development, even during break time!

The Pattern

Then I noticed a pattern by speaking to people from other companies.

Let’s suppose John is a new software engineer grad. He gets hired by a company with the a lot of promises

  • A great career path
  • Tutoring by senior devs
  • Time to learn and improve his skills.

Instead, if he gets lucky, he does a one-week introductory course on the technology he is going to use and then is put to maintain that ugly project that no-one wants to touch. The team is just a group of people working in the same room. No shared projects, no knowledge sharing, just a group of people that happens to share the same room and sometimes have coffee together. Soon he becomes the sole maintainer of his projects, he gets to know every little aspect of them; he becomes so efficient at adding features and doing small fixes that putting another person on the project would just slow down the development of new features.

When John tells his manager that he would need some time to refactor and improve the quality of the software or add tests to decrease regressions, he gets in response one of this:

  • There’s no need for beautiful code, it just needs to work
  • We cannot spend a week on something you can do in 2 days just for the sake of it
  • the client doesn’t pay for tests

or something similar.

Of course John doesn’t insists and goes back to work, after a while he gets sick of this carelessness and quits.

The manager finds another graduate to fill his position and the story starts all over again.

The Curse Of The “Invisible Artifact”

Why does this happen? Why are inexperienced people dropped on important projects? Why do they become the sole maintainers of their projects? Why is “just needs to work” a justifiable answer when you ask more time to refactor the code? Why is code quality such a hard sell on managers and other colleagues?

My theory is that, as humans, we tend to appreciate what we see but we don’t appreciate, what we don’t. Think for a second what would be your reaction if you bring your car to the mechanic and when you get it back you find that the car was fixed with a Pringles can:

It sure works but, would it bother you?

Working Software

As software developers our artifact is most of the times working software, even the Agile Manifesto says it, just “working software” not well-built-software or clean-code-software or easy-to-maintain-software. So, from the point of view of our clients and bosses, as soon as we have “working software” we are ready to ship, even if it may have bugs

Bugs in our software are good because our clients expect the software to have bugs and, if we address them fast enough, they will be happy because we care about their problems

One of my bosses

In software nobody sees the “Pringles can” or the “duct tape” that’s holding everything together, nobody sees the bottle that’s used to join two water streams, or the possibly deadly electric cable floating in the pool. But I see them, I see them everywhere in code, and if you have developed a taste for what good code looks like you to see them. Every time you find a quick fix in your code, a global variable used to pass values between two different parts of the application, an access to the database right there in the higher layer of your application you see the effects of unprofessional behavior to “just make it work”.

Of course there were time constraints and budget constraints, but you wouldn’t expect an architect to build a bridge without putting a lot of effort into every little detail of the project, you wouldn’t go to a painter asking to have a painting of daughter with crazy time and budget constraints: he can make you a sketch pretty fast but you wouldn’t be happy with it.

So, why are we happy with sketched up software, with fixes and patches put in production in a hurry and with features developed under crazy budgets constraints?

No Solution

I won’t say that there’s no solution to this problem as there are places with good software engineering culture. But, if you find yourself in a place that doesn’t understand the importance of quality in the code they build, well, I don’t believe a single person can improve the company culture alone (especially in a big organization).

 

If you have had different experience and was able to change the company culture where you work, please let me and other people know how you did it so we can make this profession a better one for future generations.

Author: Daniele Pozzobon

Daniele is an aspiring software craftsman with more that ten years of experience in the software industry. He is currently a consultant in the .Net space for a big insurance company, and previously have worked as a web dev in the manufacturing industry. He has experience with C#, Java, C++, PHP, Javascript, and lately has added some F# to the sauce.
He constantly annoys his friends by talking about software and is passionate about Agile methodologies, which gives him more opportunities to talk annoy his friends even more.
When there are no friends around to annoy, he blogs on CodeCleaners and in his free he time loves go hiking with his wife and two daughters.

  • Nicklas Ring

    Great article cant agree more

  • Sunny

    I was in a situation when on my first year after graduation I was working on the server side and was asked by the client side team to just pass the err response in a non standard way only because client side was not flexible enough to handle all types of responses. We had a little confrontation then but all seems well now and my colleagues seem to now expect me to turn this kind of requests down and not give way without a formidable argument in favour of a change. Lesson for me was to not drop your own standards.

  • So good, I had to come back and re-read. Hoping to see a part two with how I can help fix it!

  • Great article! I think there is always a balance between the business and development regarding getting stuff done. This does not mean it should affect the quality of code that is delivered. When features needs to be delivered faster, challenge the business to optimize the scope of features. What is really required to deliver the customer needs? The development team is responsible for the quality which is a team effort to protect. A definition of done publicly available for the entire organization can really help. In my experience this only works when there is a real team instead of a group with individuals working on the same software.

  • TheMeerkat

    The solution is to get more experience. Reading other people’s code will help (like reading code of third-party libraries you use etc.). And try to make the code you produce to be as good as you can. Don’t use shotcuts yourself – they don’t really help you even short-term. And do refactor – small things and only around the area you are changing, but refactoring should not take too long – couple of hours max as part of, say, two-day job.
    And remember – no amount of “Agile” or any other “methodology” will help you.