Escape Programmers Hell - Deadly sins of programming

There are 7 deadly sins in the Bible: pride, greed, lust, envy, gluttony, wrath and sloth. Each one of these deadly sins has its root in the human need for excess.

In terms of programming, these sins are reinterpreted as some of the software engineer's worst habits. Even after a lifetime of learning and practice, without discipline, some developers fall prey to their human nature. Let's see how this "deadly sins" apply to developers in the programming game.

1. PRIDE

mandria

Pride is a common trade of software developers because they see themselves as the ultimate creators - the writers of code. In the programming industry, Pride translates itself as avoiding early feedback. When a programmer assumes he knows exactly what the client wants, but doesn't communicate with him, the software suffers the consequences. The programmer has a vision in mind about what he thinks the client wants, but failing to check with the client will result in rewritten code.

There is a programming principle that states you must design the interface first. If the client doesn't like the interface, then you redesign it, you show it to him again and only after he agrees to a certain interface, you can start writing code.

Another interpretation of PRIDE in programming is "overengineering" - when the programmer is "in love" with his keyboard. That means he loves writing code, even if it's not useful. The programmer shouldn't be just a code provider, he should be a solution provider. A proud software developer will start to write code before checking if there are open source libraries available, that would fit the project. A good software developer will seek every solution available before writing a single line of code.

While writing this article, I spoke with one of our Project Managers. He asked me if I know how many code lines should be written, ideally, for a new project. The correct answer is 0 lines of code. If you're a great programmer, you will find the best solution with already existing algorithms. Keep in mind that each new line of code must be tested and retested while existing algorithms that are available online have already been tested by thousands of people.

In other words, Pride means "reinventing the wheel" in the programming industry, or not following the YAGNI (You Ain't Gonna Need It) principle.

The Devil himself (played by Al Pacino in "The devil's advocate") admitted: "Vanity is my favorite sin!".

2. SLOTH

lenea

The second "deadliest sin" in programming is Sloth. In software developers, SLOTH manifests itself in 4 manners:

  • No code review: Code review is a way to improve quality and save time because it finds potential problems earlier.
  • No refactoring: Code refactoring is the process of restructuring existing computer code, without changing its external behavior. Refactoring improves nonfunctional attributes of the software. The advantages of refactoring include increasing the code's readability and reduced complexity; these can build on the maintainability of the source-code and create a more expressive internal architecture or object model to improve extensibility.
  • No unit testing: Unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.
  • No Good Documentation: In the code writing business, documentation is half of the work. Bad documentation includes:
    • Little or no comments in the code.
    • Method and variable names are not self-describing.
    • There is little to no documentation for how the code fits into the system or business processes.

Without a clear documentation, a programmer is just cowboy coding (a cowboy coder can be a lone developer or part of a group of developers working with minimal processor discipline).

In a manner of speaking, a little sloth can be good for a programmer, in the sense that most brilliant ideas come from trying to simplify a process. But this can also be a huge problem in the development process if the programmer leaves out comments or fails to run automated tests out of laziness. Some software developers consider that unit testing is not their headache. They believe that time spent testing is time not spent implementing features. The more you plan for unit testing before shipping a code, the more damage control you can avoid later. By the time the code arrives at the client, it's too late to undo your mistakes. Leave your pride aside and do what is in the best interest of the project and for the client, instead of thinking you can do no wrong and ship a bad code to the client.

3. LUST

In the programming world, LUST means striving for perfection, at the risk of missing a few deadlines. Software development is constantly growing, and new development methodologies appear frequently. Modern-day languages tend to add new features, piling layer after layer of abstraction, with new keywords and structures designed to aid code readability and reusability, if you take the time to learn them properly. Otherwise, trying a new framework you just heard about, on your very important and urgent project, might cause you to miss deadlines. Just because you can do something doesn't mean you should.

4. GLUTTONY

aviditatea

In software development terms, gluttony can be perceived as writing too much code. Every hour spent coding will require an extra hour of testing, and possibly two more of maintenance. You should really consider if you absolutely need to write these code lines, or it's just gluttony because you love to write code, regardless of its importance and functionalities.

5. ENVY

For software developers, the Envy sin manifests itself as not using version control. In computer software engineering, revision control is any kind of practice that tracks and provides control over changes to source code. Software developers sometimes use revision control software to maintain documentation and configuration files as well as source code. Powerful and effective version control systems are available for free. There are also service providers available to host code for distributed projects for minimal cost. There is no reason why you shouldn't make starting a code repository one of the first steps in any project unless you can't stand to see anyone commit code changes but yourself.

6. WRATH

mania

Wrath translates itself into the programming world as hostility towards your fellow programmers. And what is more hostile than failing to comment on your code? It's true that well-written code is its own best documentation but it's also true that this code might live on long after you quit your job, so have some mercy and leave a few comments for the software engineer that will follow in your footsteps. And try not to leave redundant comments explaining simple operations, like variable initializations.

7. GREED

Software developers are very competitive - so competitive, that sometimes it might even damage the project. If developers fail to include everyone from the project on the mailing list, they might end up with a team that has written a library that reimplements more than half of the functionality already coded by another team. One of the top priorities of managing a development project should be making sure each hand knows what the other is doing and working together toward the common goal.

There you have them - the 7 deadly sins from the Bible translated into programming sins. But there are other "deadly sins of programming", that are not in the Bible, but they should be!

Other programming "sins"

After talking to Kepler's software developers, I got this extra list of don'ts in software development:

  • Writing before thinking: you must ALWAYS read the product requirements thoroughly before writing a single line of code. Think about how are you going to test the result, think about what algorithms you are going to use.
  • Not using open source libraries for functions when there are plenty available (overcoding).
  • Writing bad documentation
  • Over-segmentation: making a class for every other variable, creating a function for every 2 lines of code, destroying readability
  • Not keeping each line to a maximum of 80 characters
  • Not staying up to date with the newest technologies (this can also be considered SLOTH)
  • Not providing helpful error/exception messages
  • Using poor and incoherent names for variables
  • Not looking at the big picture - How do you feel when you've just fixed something, only to realize that your fix broke something else? (that's why we have unit testing)
  • Letting dead code stick around (the YAGNI principle)
  • Not understanding the problem domain before developing use cases
  • Blind copy-paste from sites like stackoverflow.com and not going through the explanation and comments
  • Lack of indentation - most IDEs have a shortcut for that - use it!
greseli

To all these programming sins, there are two mistakes that every employee should take into consideration, not just software developers:

  • Being a bad communicator: Thinking that just because you are a software developer, you don't need "people skills". WRONG! You must learn to speak clear, concise and to the point when talking to your colleagues, superiors or clients.
  • Not caring about your company's business: how can you build a product that will fit the customer's requirements, if you don't know and understand the company's business?

Escape programming hell - join our team!

"We see a deadly sin on every street corner, in every home, and we tolerate it, we tolerate it because it's commonplace because it's trivial, we tolerate it in the morning, noon, and night. But not anymore! I'm setting the example. And what I've done is going to be puzzled over and studied and followed forever", said John Doe in the movie Seven. And we agree! At Kepler, we try to set an example of sin-free coding. Our developers are solution finders, not just code-writers. Our senior project managers enjoy sharing their experience with young developers, in the training sessions held during work hours.

If you want to work in a "heavenly" environment, among some of the top developers in this country, and learn how to write clean code that works, send us your resume!



Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
Copyright © Kepler Rominfo Legal Notices