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.
As more and more things are being automated, our daily life becomes easier. In many cases however we have a mix of automation and manual actions, or we want to be able to intervene or correct when automation goes wrong. Whatever reason, a fully automated system is often still not feasible, and thus manual interactions needs to be allowed and taken into account during design and implementation. But what exactly are the implications of this?
Recently I took a CUDA course and one of the things they mentioned to keep an out for was the usage of double precision. Double precision operations are slower and the added precision wasn’t worth it, so they say. This made me wonder whether this is also true for regular programming with languages such as C++ and Java. Especially because both of these languages have a double precision as the default floating point number. So how bad is it to use doubles instead of regular float, and what about that precision. I have investigated this in Java.
When re-working an existing application I was wondering whether I should continue using Angular Material Design or just switch to Bootstrap. While I have used Bootstrap in the past when working with normal HTML web pages, I never used Material Design. The only experience I had was how the application looked like, and that was horrible. My first reaction was to just start over and use Bootstrap instead of Material Design, but the decision was not that easy as I hoped it would. In this blog post I will compare Material Design and Bootstrap.
As mentioned in the previous blog post, I will continue with my remarks about some Angular 4 design choices, similar to what I did in the previous one. The course I followed was very in-depth about Angular 4, but there may still be things I do not know. I am not an expert in Angular 4, and my real life experience with Angular is very limited. I am aware that this may influence my opinion and cause me to dislike certain choices while better ways to do it exist. I am open to this, and please let me know if you have any comments or advise for me.
Recently I followed an online Angular course, giving me an in-depth experience of both TypeScript and Angular 4. This was my first experience with both technologies and they look very promising, but I can’t help to have a couple of remarks about some choices that have been made. In this blog I start with giving my opinion about some of the choices made in TypeScript. In the following blog post I will continue with my remarks about Angular 4.
Because I have only seen TypeScript in combination with Angular 4, I may confuse features by mistaking them to be part of the one or the other. I am by no means an expert in either Angular 4 or TypeScript, so please forgive me when I make mistakes like this. I would also like to hear your experiences and comments.
Software has a very unique characteristic, you create it once but can deploy it as much as you like. This goes beyond the limitation of other industries such as architecture, manufacturing, etc. In those industries you design it once, after which you can mass produce it, but the production itself has to happen every single time. Software is not bound to this as it does not deal with any physical objects. This makes software a good fit for a product approach, were it not that people have different preferences and like some customisation.