Another year has passed, and even though it feels like I say this every year, what a year has it been. As is my yearly tradition at the beginning of the new year to look back on the past year and look forward to the next, so I will do this year.
During software development we use many tools such as the IDE, code coverage, static analysis and build tools. There exists many of these tools with each their advantages and disadvantages as well with differences regarding personal preference. Being able to work with tools you feel comfortable with is important for your efficiency. Because of this different people might prefer different tools, but how should this be handled when working in a team where having a uniform setup has its own advantages.
Every software developer should be familiar with some type of versioning system, be it git, Subversion, Mercurial or some other. The advantages offered by using such a system are plentiful, they are that vast that such a system is often also used for other types of documents, be it in a different format. Services such as Google Docs, OneDrive or Dropbox offer the exact same features because they have recognised that having a history of your documents goes way beyond source files.
So we all acknowledge that keeping your data in a versioning system is a good way, but this opens up a different question. How should you organise your documents? I don’t mean which folder hierarchy, which in itself is already a challenge, but I mean the actual location. It makes sense that you want to keep your files close together, but how do you categorise your documents? Based on topic, type, target audience?
One of my biggest remarks when working with Java the past few years was the lack of a strict immutability concept. The most you can do is declare your object to be final, which only prevents changing the object being pointed to and not any changes made to the object itself. I remembered that C++ offered a lot more opportunities for this and you could go crazy with the ‘const’ keyword.
However, during some quick investigation regarding this constant behaviour for the GroceriesInsight project, I discovered that I was a bit off with how C++ handles the constant behaviour of arguments passed to a function.
After a long period of being bored at work, doing meaningless tasks and no real software development, I decided to switch jobs (again). Although I only worked there for little over two years, the situation has changed in such a way that staying is no longer an option. It’s a long story which started with a take-over causing a lot of confusion and uncertainty about the future. After this announcement a few people already left, but it wasn’t until that they re-organised the way of working, which completely destroyed the software team, and split it up into separate developers that it all went wrong for us. No effort was put anymore in advancing the product we had, no new projects were sold, basically all development came to a complete halt.
Depending on what type of business you are active in, you either often start new projects from scratch, or not at all. In the first case you are more involved with proto-typing and experimental work whereas in the latter you are working on a product that needs to be supported, upgraded and maintained.
Starting code from scratch has a lot of benifits mostly caused by the freedom that comes with it. You are not bound to any choices made in the past, you are free to choose your own way of working that you are used to and feel comfortable with. There is also no legacy code that you need to understand and may be badly documented.
But what I want to address in this blog post is all the side-setup that is required when setting up a new project, and how important it is. Should it all be done from the start? Or can you delay it until it really becomes important?
As CPUs have more and more cores available, big performance gains can be achieved by having your application take advantage of running tasks in parallel. An increased level of parallelism however introduces more complexity. An intinsic problem when trying to run things in parallel is deciding what to run in parallel. The amount of tasks than can run completely in parallel are seldom and some type of synchronisation will be required most of the time, already decreasing the possible gain you can make.
Another problem you face is to determine how much you want to run in parallel. Do you want to start a thread for every single small task you can think of? Or do you want to have a couple of bigger threads? Since you know that creating threads comes with a cost, but can you avoid this cost by using a thread pool instead? There are so many questions to be answered when starting to work with parallelism, but today I will be focussed on determining how much threads you should have running given a certain capacity of the CPU.