The obligation of a software developer

We live in a world that changes everyday and software is one of the biggest part of that change. People interact with software in many ways, such as their laptops, their smart phones, their cars and they expect to get the most out of the devices they use.

Behind the software applications are the teams who build the products and the factors that determine the success or failure of the software are strongly connected with the cohesiveness of the team, the amount of effort the team has put during the delivery and the behaviour of each individual. In this article we will explore some of the ethics that a developer and a team should have during and after the delivery of a software product.

1. Find the best solution and not a solution
   As mentioned in the introduction, a significant factor that will determine the long-term success of a product, is the quality of the solution we are offering to the client. There is no reason to deliver a solution that is going to slow-down the product, make its state unpredictable or make the UI looking different from the one that your UX designers proposed. And this is simply because the quality of the solution and amount of effort, show the respective respect to the client and/or the future user. The high code quality in the codebase will also make the experience of the current and the future developers significantly better.

2. Do not write code you do not trust
   A codebase without unit tests or any kind of tests, contains code that cannot be trusted. And why should you deliver a website, a SPA or an app to a user with code you don't trust? The answer is that you should not. The tests are the first line of defense in a codebase, they are the part of the code that will give you the heads-up when something goes wrong and they are going to catch the bug faster than your console.log('Hello'), they are the part of the codebase that will explain to the software developer or the QA tester the purpose that your code serves. Also remember that the tests are the units that prevent you from writing unnecessary code. So always aim for the highest possible amount of code coverage for your benefit and the benefit of the future user. A codebase should include 15% UI tests, 30% integration tests and 55% unit tests. The unit tests should always be close to 100% code coverage and they should cover as many cases as possible.

3. Learn how to say No. But also learn to negotiate.
   I am glad that at the early stages of my career some Scrum Masters and Solution Architects taught me the value of saying No, but also how to negotiate to make the “No” a compromisation that works as a solution for the benefit of both sides. They taught me that if I don't raise my voice and say that “this, this and this can't be done now or in that way”, then I will end-up with unnecessary amount of pressure on me. And it's true. Unrealistic deadlines, unrealistic requirements and unrealistic delivery will be part of the discussions during development, but you have to find the correct arguments to defend the fact that some things cannot be done by a certain deadline or in the way they are proposed. It is the worst form of unprofessionalism to make a commitment that you can't keep, or make false delivery just to think that you keep your line manager happy in that way. The opposite may happen.

4. Respect your team members
   Your team members are the people you meet every day for at least 8 hours per day, the people that you have long meetings to find the appropriate technical and non-technical solutions, the people you speak with every day. There is no reason to create tension, and change arguments that may harm the cohesiveness and harmony of your team. And if that happens, it is your obligation to discuss the issue with your team member/s and resolve it as soon as possible. Also in a team there should not be a person who should think that is doing better job than the others, or that the depth of knowledge gives them an advantage to behave in an inappropriate way. If someone encounters an issue, then there should be the appropriate support and mentoring and help that team members or team members get back on track again. If there is success, then your team celebrates as a collective. If the product fails, then the team fails as a collective. At the end of the day, what's the meaning of a team that is just a disarrayed set of individuals?

5. Enhance an implementation. Do not criticise it.
   I am at the second year of my career and code review is the part of the development that I always consider an enjoyable task, because it's a good chance to sit down with your colleague and think as a collective how to enhance the implementation that has just been committed in the codebase. It's an exercise that should be happening in all development teams, as the developers are the people who should spot a mistake in codebase in the first place and improve an implementation to make it faster, better and more generic. The criticism and the advice should always be constructive, it should include the “why” your suggested implementation is better than the existing one and your advice should include examples from previous implementations. However, any kind of advice or suggestion should never be said in a judgemental and tough way, as the code review is a team exercise and not a chance to judge your colleagues just because they have done a coding mistake.

Mentoring is also part of our job and it is always required to help others improve and bring them to the level of the rest of the team. As Eric Elliott says in his article “The Essential Guide to Building Balanced Development Teams”:

In a mentorship culture with lots of pairing and code reviews, even novice developers quickly become great contributors.

There is nothing better and greater than mentoring Juniors and see them becoming great developers just because your advice had an invaluable impact on them.

Great software is built by great teams, where the culture within the team is such that allows them to outwork the most difficult challenges. It is also the obligation of each individual to have the right mindset when developing a feature in order to deliver the code in the appropriate quality level.

Comments

[Bryan Ellis]

Having been a developer for 30+ years I find it fascinating how schools can expel new developers who can't read and maintain existing code. Careers in literature require a lot of reading and understanding of the language before the first new literary work is created - let alone published. Science requires a lot of procedure following behind those who have come before. Software development seems to forego all of this and instead says "read the dictionary then write me a novel". Too many coders can only build new things from scratch and have a very difficult time maintaining existing (many times legacy) code. This skill would help in points 4 and 5 of the article. Remember that not all code has the privilege of being created in the newest, best, cleanest environment.

[Nick Sweeting]

This maybe because everyone gets Computer Science degrees instead of Software Engineering degrees. People mistakenly think the two are the same, and come out of university with their fansci compsci degree without knowing what Bash, git, or TCP/IP are.

[Kristina]

I think it depends on the program, and not necessarily just the degree. My CompSci degree included a pretty in depth focus on Bash, git, TCP/IP and actual practical skills. But, I've seen other schools that are way too theoretical. ¯_(ツ)_/¯

[Nick Sweeting]

Makes sense! Where did you get your degree if you don't mind me asking? It sounds like your school did it right!

[Kristina]

Don't mind at all :) McGill University -- in Montreal. But I've definitely taken classes at other schools where there was no emphasis on actually coding as well -- which is...worrying :/ [Edit: Just realized you're IN Montreal! Awesome!]

[Nick Sweeting]

Oh nice, I'm in Montreal too. I've heard good things about parts of McGill's compsci program.

[Tobias Salzmann]

I purposefully avoided any practical lecture in university. Even now, after deciding on a career in Software engineering, I do not regret that decision. The reasoning and problem solving skills I developed are much more valuable to me in my day-to-day work than knowing about some specific technology could ever be.

[Erebos Manannán]

To me this "find the best solution and not a solution" sounds rather crazy. You'll spend your days trying to figure out the best way to do things, instead of actually accomplishing things.

You'll end up in a situation like this

while (true) {
  findBetterSolution();
}
implementSolution();

Of course you should not just rush into things and do the first thing you can think of, but wasting your time looking for that mystical "best solution" is crazy. Iterative development is generally the best way to do things: Create a "good enough" solution, that has been developed based with some thinking, and then if there are issues with it later fix them then.

When you set up your own business you will soon realize you can't just sit in a dark room forever implementing your "best solution" and do need customers to use your "slightly less than perfect solution" to get money in, and to get real feedback from. The assumptions you make about a "best solution" without any real user feedback are simply going to be wrong and are going to lead you down a path of a lot of wasted time and money.

[Steve Steiner]

I thought exactly the same thing.

A wise man once said: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"

But first, we have to know which 3% and chances are really, really, really good that it's NOT the little chunk you're hung up on trying to find "the best" solution to/for.

Paralysis by analysis is a real thing and slows everything down while the "loop-ee" doesn't even realize they're executing an O(∞) search algorithm.

[Erebos Manannán]

Indeed.

There are certainly cases where I can say "this is a critical path that I should spend some time optimizing more", or "this part is going to have to cope with a lot of different situations and I should think about it in advance", but in most cases "hey this works" prevails.

Sometimes a day, a week or a few months later I see "oh, didn't expect this to happen, now I guess it needs some refactoring", but that's a lot better than having delayed everything else I worked on by trying to predict the future and accomplishing nothing.

[Ioannis Mavroukakis]

Interesting article except from your test percentage claims, they feel a little hand-wavey

[SteliosVoskos]

Kalispera! I would agree with you that when you have a lot to do, these numbers may seem unrealistic. It's a common thing and there is no issue with it. There are two things to keep in mind though:
a) 100% code coverage is an asymptote and a number to keep you a bit mindful on your tests. You can never reach that number, but you can be somewhere close to it. For example, recent project I was working on had 83.7% and we were happy with it.
b) Even if you think that you are too busy to write your tests, you have to remember the most basic law in TDD, which is that you have to write the minimum amount of code to make the test pass. That's why TDD reduces bug density and development effort.

Also remember that TDD and testing in general is a discipline and you get better and better with it over time. Happy coding my friend!

[Ivan Areeba]

Thanks for sharing this Stelios. It helps alot in our area of software development.

[JanGroot]

Have you seen Uncle Bob's talk on this? m.youtube.com/watch?v=Tng6Fox8EfI

[Carlos]

Good article; very enthusiastic and encouraging. You don't see much with those qualities written these days.

[Kresimir Bojcic]

Nice article!