What is good code?

This is one of the biggest questions in programming. Everybody has an subjective answer to the question, as everybody develops their own style of programming over time.

For me good code has to fulfill these 5 criteria:

  1. Correct
  2. Efficient
  3. Simple
  4. Readable
  5. Maintainable

Now lets take a closer look at every criteria and what it means for your programming project

Correct

Code should have one key feature: It should work. Not functioning code is useless code.

Code has a very specific task it should do and it only should do that task. It should not do anything in addition that you do not expect.

Correct code also implies that it was built to specification . If you have a specification, you also can ensure that your code is correct by writing tests that verify that the code is doing exactly that what was specified.

Simple

If you have the choice between a complex expression and a simple expression that solves the same problem. then use the simple expression.

The complex expression is always a big door for unintended bugs. Additionally it makes it much harder to explain what is going on with your code.

Efficient

Efficiency, strongly depends on the values / non-functional requirements of your project.

It means if you can avoid costly operations, duplicate operations or unneeded operations. then you should optimize your code to avoid these kind of structures.

If possible you also should optimize for performance, however for most algorithms you need to decide a trade-off if your code will use a lot of memory or a lot of CPU. Before optimizing you always have to define for what you are optimizing.

Readable

Code is written for humans. Another human should be able to read your code.

If you use complex structures it just makes it harder for someone else to figure out what is going on in your project.

The compiler does not care if the variable is called “f” or “isActive” in both cases the compiler produces the same bitcode. Naming things is very important.

And never forget in most cases you are going to be the one that will revisit the piece of code and you will not know anymore what “f” is, but will immediately understand what “isActive” means.

Maintainable

Code is never done. There are a lot of things that causes that code needs to be adjusted in the future:

  • Additional Requirements
  • New Features
  • Dependency Upgrades

Now you can say, screw the maintainer of the project, you are only concerned about today. – However in most cases the guy that needs to fix something is the guy that created the code in the first place. – So do yourself a favor and write maintainable code.

What does it mean to write maintainable code? Have documentation, encapsulate functionality in a way

Conclusion

In the end good code is whatever you want it to be. If you are working with embedded systems and you want to create the most efficient algorithm, you will probably have other values as when you are working on a Web-Project.

You can define whichever values you want. The important thing is that these values must be clearly communicated to your team. Ideally by you leading as an example the others can follow.

In the end the goal of good code is that your project should deliver on time, suffer from less bugs, new team members can be easily onboarded, the team writes better tests and overall better communication (the specifications have to be more precise) etc.

Sources:

ImageDesigned by Freepik

Ranking Programming Languages

A recent article on InfoWorld titled Breakthrough: Python reaches Tiobe index Top 3 – Yey Python – But wait, what is being ranked?

The TIOBE Index uses search engine data to extract which languages are popular.

That is a questionable way of figuring out if a language is popular. It only means people are searching for a language. Does the search data separate between Java and JavaScript (two very different languages)? Are the searches for things that are difficult in the language and unclear. Basically if a language is badly documented = more searches => higher on the index. The more issues and frustrations you have with the language will rank you higher.

If we take a look at the 2017 results unsurprisingly Java takes the Number 1 spot. As many companies use Java and many universities teach Java. Thus a lot of people are searching for Java. – However programmers are actually starting to dislike Java, as there is currently so much poorly crafted Java-code in the world that desperately needs to be rewritten. In addition the Java community is facing a lot of problems with rapid unwanted changes from Oracle. (*Note: Java is a great language that strongly promoted object oriented programming and is a great tool – it is just in a wierd phase right now.)

Interestingly on position 11 we have Delphi / Pascal. A programming language I have used the last time over 17 years ago. I doubt any company is still using Pascal applications. However as a part of programming language history it is quite interesting. And there was of course a spike last year as a new version of the compiler was released. (https://www.freepascal.org/) Also schools with outdated curriculums still teach Pascal…

I am not sure what information I can gain from this type of ranking. It could mean that Java is a mess because so many people are googling their problems with the language and an old language Pascal is now suddenly on the rise and will become the next big thing?

How would I rank programming languages?

First we need to figure out who needs rankings of programming languages. My guess is people that want to start learning a programming language, people who want to see trends in the industry and managers who need to make project decisions.

Before we can even begin with ranking the languages the first stumbling block. Depending on your project you may be already locked in with a specific language. In many cases you want to start building on things somebody else is providing you, a Web Browser (JavaScript), a mobile device (iOS: Swift/Objective-C, Android: Kotlin/Java) a game engine (Unity – C#, Unreal – C++), etc.

Simply put if you have a defined project, just start working on the project. The language might be already defined and you do not need a ranking.

A person who wants to learn programming

This list should take multiple things into consideration. The person learning has practically no knowledge. The person has to learn everything from scratch. The important thing is to start learning programming concepts. It should be easy to learn, ideally avoiding advanced stuff like compilers and static typing (and preferably a language also used by the industry and not university only).

This leaves a rather short list:

  • Python
  • JavaScript

These two languages are dynamically typed and at the beginning still very forgiving for mistakes. Both have tons of documentation.

Starting with JavaScript is really easy, just press F12 in your browser and you can get going, no installation needed. It also simultaneously teaches you concepts about HTML and Networking. Concepts of Object Oriented Programing as well as functional programming can be learned. And variants of the language like TypeScript can explain the value of static typing and what a compiler does.

Starting with Python is a little more difficult. As you first have to install python etc. The other thing is of course the meaningful whitespace, which is wierd for a beginner but at the same time the best way to get a beginner used to the idea that code should be beautiful and readable.

There is no real ranking – just choose one of the two. Both are equally well suited as a starting language.

I would take a look at how many new projects are being created in which language. Statistics from Github from their Octoverse Survey

  1. JavaScript (2.8Mio)
  2. Python (1 Mio)
  3. Java (0.9 Mio)

Of course this is only from one source and you would have to add multiple sources to get a better picture. (In this case we only see values from OpenSource projects). If you want to see trends you can observe these values over the last couple of years.

For business people

Here we need to take the money aspect into account. Just because “Java” appears at every top list of backend enterprise web development – that does not mean it is currently the best business choice.

One of the key indicators could be how verbose a language is. As research has shown that a Java Developer and a Python developer take the same amount of time to write the same lines of code. – However a Python program can need in some case 30% less lines of code to do the same function.

From the http://helloworldcollection.de/

Python Hello World:

print("Hello, World")

Java Hello World:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello, World");
    }

}

You would have to take a look at long term maintainability of the language. Basically: who is maintaining the language – will it still exist in 10 years?

  • Java is supported by Oracle, that is messing around with the business model surrounding Java, so maybe not.
  • TypeScript supported by Microsoft, and Open Source (worst case you are going to need to maintain it yourself)

Another important factor is tooling and ecosystem. If the ecosystem is dying then it may be a good time to switch languages.

And of course the last factor would be how many programmers are currently listing the language as one of their skills. (there are programmers on the market that you potentially could hire to work on your system)

Depending on your project you may need to take hardware costs into account.

Unfortunately there is no universal approach to this multifaceted problem. Depending on which factors are important for your project you will get a different ranking of possible languages for your project.

Conclusion

There is no singular good way to rank programming languages. However whenever you encounter a list or ranking of programming languages just be aware of what techniques they used to create the list.

Credits: Image: Evaluation System Designed by Makyzz / Freepik

Dealing with the new Java Release Schedule

Oracle has just announced that the End of Support for Java 8 is going to be January 2019. This, in turn, means that every business using Java will need to upgrade for security reasons to the latest version of Java. The new release strategy says that newer versions have a 6-month support and then a new major version of Java is going to be released. In Addition, they are changing the Version naming scheme from SemVer to <year>.<month>Basically allowing Oracle to introduce breaking changes to Java every 6 months. As a business you basically are given the choice:

1. Upgrade Java every 6 Months

If we would go with the first option it already gets strange. At the moment assuming you are currently on Java 8 you would need to directly update to Java 10, as Java 9 Support already has ended. However, you still would first need to update to Java 9 just to see what all does not work anymore due to Java 9 major changes and then move to Java 10. But that is assuming that your 3rd Party libraries also already did the update to the new version. Then in September, you would upgrade to Java 11. A lot of people are going to say, well good then we just do not upgrade now and wait for September to do the upgrade. Yes, you can do that, but that does not really matter as in the following March you anyway would have to upgrade again. Your business needs a new strategy how to deal with the rapid version changes. That is now only supported for 6 months instead of the ~3+ years. Personally, I really like this, as most businesses have the strategy: “Version upgrade? only when hell freezes over” – that only costs money and has no immediate benefits.  Focusing on the short-term impact, neglecting the fact that continuous upgrades are cheaper in the long-term and contain less risk compared to the big bang upgrades. Source: Java Release Roadmap

2. Get Java Advanced licenses (Extended Support)

The alternative is to just get the Java Advanced license. I could not find any information on the Oracle site. Basically, you are paying around 500usd/core (Source), so depending on how many servers you are using you will have to pay a small fortune. At the same time, you are only sidestepping the upgrade issue as you anyway have to upgrade your system every 3 years at least once.

3. Use another Language

Depending on your codebase you may want to look into moving away from Java. If you are starting a project you may want to look into C#, Python or JavaScript (or any other language) Many Java projects are anyway already running for 15+ years and may need a technological overhaul. You could think about switching to micro-services and start replacing a service one by one with another technology. While there are many costs and risks involved switching technologies, *developer training, system stability, continuous support etc. etc.

Conclusion

It really depends on your project and how your business deals with change how you ultimately deal with Release Schedule.  You definitely need a strategy how to approach this problem. The future of Java is unclear. Oracle is promising more rapid improvements of the language.  But there is the possibility that the changes are too drastic so that businesses will stop using the language. Either Java will continue to be one of the most used programming languages or fade into obscurity. The only thing that is certain is that the world of Java is going to be changing significantly in the next couple of years.

The Joel Test

In essence, the test is a quick 12 yes/no Questions that allows you to quickly determine how good your development workflow really is. anything below 10 and you are usually in big trouble in the long term.

Now let’s go a little deeper into the questions and what you would need to do to fix these issues. At the end, I put a list of my revised questions.

1. Do you use source control?

Now in reality, if this question is answered with “No” you are royally screwed. If this is answered with no, then stop right now and take a look at git. Even when you are working on your own project that does not be synced with a remote repository you should use git. It is easy to set up and there are a lot of providers like GithubGitlabAtlassian Bitbucket if you need to sync it over multiple computers.

The bigger question that relates to this is: “Does every team member understand the Source Control workflow?” The most popular workflow is the GitFlow it is easy to understand and new team members can understand immediately what is going on.

Does your Source Control integrate directly into your build system?

2. Can you make a build in one step?

In most modern development projects this is not enough. If you are doing a Web Development Project, you can use tools like nodemon(Auto reload for NodeJS) or Hot Deployment (Auto reload for Java / Tomcat) to ensure that you constantly build your server. Similarly, you would use something like the webpack-dev server for the frontend.

What I am saying is, you are anyway constantly doing builds of your software. The bigger question is can you also deploy your build without effort? It does not have to be onto a production system, but it could be a testing-server or some other staging system. So when you have to deploy to production you can ensure that it is as hassle-free as possible?

3. Do you make daily builds?

The question should be “Do you deploy daily?” – Whatever you are creating needs to be seen by as many eyeballs as possible. So that the Feedback can get back and influence the development as early as possible. Also, the client should profit from improvements as fast as possible.

This, in turn, does not mean that you should skip testing or quality assurance. It only means that stuff that is production ready should be shipped as soon as possible.

4. Do you have a bug database?

Now bugs are bad, and you need to know about them as well as which features you want to create for your product. So the more pressing issue is how are you tracking all of the development efforts you are putting into the project.

Instead of a bug database, you should have an issue tracker like JIRAor the integrated bug tracker from Gitlab.

The other thing to consider is a dedicated website for “Help us improve our product..” or a publicly accessible “bug database” so everyone that is using your product can easily report issues they are having with it.

5. Do you fix bugs before writing new code?

Well nothing to add here, fix your product before shipping new features. This is more an issue of business intent vs development. Usually, Sales will pressure you to ship faster and will try to cut corners. However, this practice is very expensive in the long run, as customers expect high-quality software. By Apple advertising their products as “magic” the expectation of high-quality software is now the norm. Cutting corners and not fixing bugs is no longer an option. Customers that have the feeling the software is buggy will look for another piece of software that has a higher quality.

On top, of course, is that the longer the bug exists the more money it will cost to fix the bug. So there are enough incentives to first fix bugs and then move on to the new features.

6. Do you have an up-to-date schedule?

Programmers hate schedules. It does not matter if you are ‘agile’ you need to estimate the work you are doing and match it with reality. Only then you can ship things with confidence. Developers need to learn to make a schedule for themselves and not work 14 hours a day just because they did not finish.

But what about extra features? well yes that is called scope creep and yes that needs to be regularly discussed and the schedule adjusted accordingly.

7. Do you have a spec?

You need a spec to start any work. If it is not specified it is unclear what you should build.

That is not an excuse for not specifying exactly what you need at this moment.

8. Do programmers have quiet working conditions?

Now this one is critical for every developer. However ‘quiet’ refers more to that the developers are not constantly interrupted. Have rules like: google it for 5 min before asking a fellow developer. Interruptions of a programmer can cause delays of up to 30min per distraction. To have efficient developers do not interrupt them and let them listen to whatever music they want.

9. Do you use the best tools money can buy?

Every developer has his own personal preferences, allow them to use the tools that they want. Some of the most awesome tools available VSCode is a free tool. Other things like JIRA, and IntelliJ are well beloved and cost a monthly fee. This money is well spent if the developer is happy and gets support from an industry leading tool.

I have seen Java Developers that switch to IntelliJ that were then up to 20% more efficient as before. The program drastically improves code quality and speed in which you develop code. In addition, it has the feature “Inspect Code” that analyses the code for potential quality improvements etc.

10. Do you have testers?

testers should take a look at the software. This includes automated tests, Unit Tests etc. You need to have a Test suite set up to be sure that changes do not affect other parts of the software.

Human Testers should also take a look to ensure that even really unexpected situations do not make the program crash.

11. Do new candidates write code during their interview?

This is a very important thing. HR People have no clue about coding, they cannot evaluate if the developer is suitable and can be integrated into the current team. By enforcing that you need to code in the interview somebody from the dev team needs to be present. That means he also can evaluate the potential hire, plus the potential hire can show off that he has some skills.

This, however, is widely misinterpreted by companies. Some companies have an exam that is more like “find the missing ‘;'”, or other similar trivial mistakes that are found instantly by a compiler. Or in another case a company wanted me to complete a task that would require 2days of development effort.

The programming task should be something that is simple and relates to the position the developer is applying for and that can be done during the interview, so it must be short.

12. Do you do hallway usability testing?

“Eat your own dogfood”, people in your company should be able to use the product without any explanation of it. If your own employees cannot use the product or understand what is going on, how should they sell it to a customer? It builds confidence in the dev team that you are doing the right thing and that other people (non-developers) understand what is going on.

Only other Developers are interested in what awesome code you have written. Normal People only care about if they can use the program. Usability is key to any successful piece of software.

The Joel Test V2

  1. Do you use source control? (Does every team member understand the associated workflow?)
  2. Can you build and deploy in a single step?
  3. Do you deploy daily?
  4. Do you have a ticket system for features, bugs, maintenance?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule and devs schedule/estimate their work?
  7. Do you have a spec?
  8. Do programmers have a quiet / interruption-free working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have Quality Control (Automated Testing, Human Testing)?
  11. Do new candidates write code during their interview?
  12. Do you do usability testing?

Source: The Joel Test: 12 Steps to Better Code

Image: Designed by Freepik