The first thing to add is of course a way to add products and transactions as these form the core of the application. With the initial version I am aiming for a very basic form which just allows storing and retrieving data.
With the initial implementation of the Product and Transaction done, I will briefly explain how everything went, the thought process behind it and what I already know must be added in the future.
Before starting any actual development I decided to dive into the features GitHub provides. Since it is just a personal project, I see little reason to start hosting my own Jira or other heavy applications that I would need to keep running somewhere. Instead I would opt for free cloud-based solutions. As a fact I know that GitHub has a lot of features, which is nice because then everything is located in a single location.
I have however never used any of these features, and thus I was out for an interesting journey on setting everything up. In the end the goal was to have a nicely organised repository with a clear flow, where merging branches and continous integration is standard.
In the past I tried to contribute to an open-source C++ project, mainly because I want to keep my knowledge of C++ up-to-date. However finding an interesting project has been tough, but eventually I did find one. However, as with all projects there is a quite a big learning curve to get involved. Due to my lack of time, this never really took of.
Recently I decided to start working an a personal project, as with all of these projects they arise from a feel of need. The application I will create has as main goal to keep track of expenses. There are probably a lot of other applications that can do this, but by doing it myself I will have more control over the features.
Depending on what type of bussiness 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.
Except from some small (personal) projects or tools, is software development a team activity. The bigger the application the more people are involed, and the longer the process is. Starting with a functional analysis all the way to operations, you have many different type of people all with their own function. However, the more the functions are split up, the harder it is to keep ownership and take responsibility and more often the blame game is played. This is simply caused by the fact that it also becomes easier to make mistakes because information is passed on multiple times, and different people will interpret things differently. But even just in development, depending on how you organise the process you can easily cause people to live on their own island.
When writing software you will end up using frameworks and libraries to make your life easier. Even if you don’t use any frameworks or libraries you still have the language itself that can evolve over time. A nice example of this is the recent release of Java 9 which did introduce some changes that might break your software.
All of these dependencies could become a hell if you are too tight coupled to them, as they restrict you from upgrading or changing when required. It is essential that you take this into account when writing software but as always it is easier said than done.