Software Engineering Blogger

Software Engineering — Building layers of the cake instead of slices of the cake. In software development you could go into separate rooms and build slices of a cake and combine it all into a single cake hoping to have a good cake. The following alternative is better. Build layers of the cake and that will naturally lead itself to early integrations, early visibility to software functionality from the product management and the end user point of view. Isn’t this what agility is all about? Almir Mustafic

Software Engineering… Programming is an act of giving a machine some instructions so it can perform things repeatedly. Software engineering is an act of programming and everything else that goes along with it in order to deliver enterprise software to production. Within software engineering, the more time you spend coding your applications and less worrying about DevOps things and processes, the better for you. Make sure you are heading in the right direction. Let’s say you use a cloud platform to run your applications. The whole point of a cloud platform was to abstract things for developers in order to spend more time coding applications and less worrying about how to set up the resources in the cloud platform. So if you are hiring a lot of DevOps experts, then it means that the platform itself did not abstract the cloud enough. In conclusion if the act of software engineering is close to the act of programming, then you basically reached that ultimate point where your techn...

I had to remind myself about this as I worked on Unix/Linux platform a long time ago and having been in Microsoft shops for many years did not help either :) If you want your environment variables (being set up by another script) to be properly set up in the context of the window where you are running the script, you have to  run the script with a dot and a space in front of it  as shown in the screenshots below. Screenshot of vim editor showing you the content of setup.sh script: Executing the script in bash window and then verifying if an environment variable is set up: Thank you for reading. Almir Mustafic

Code kids? Let me start by saying that I was NOT a code kid. Generally speaking a code kid is a kid that starts programming at early age and by early age, I am talking about 6 to 12 years old. I was good in math and science, but the first time I was exposed to programming was in grade 8 which is considered late by code-kid standards :) In grade 8, I was writing code on paper and asking one of my friends to borrow his Commodore-64 to see what it runs. I was excited to see my first for-loop working. When I really got into it, I was in grade 11 and 12. I enjoyed it and I have been deep in this world ever since. There is a level of satisfaction that programmers get when they figure out a problem after hours of troubleshooting. It is hard to explain until you experience, and you also can experience it. Does every kid need to end up working as a software developer? No, they don’t, but being introduced to programming in early days is very important for exposing kids to different ...

When you have a problem to solve, what is the most typical way to approach it? Everybody is different, but most of us try to stay within our comfort zone because that’s what makes us feel more stable or more secure. We have one tool and we try to solve all the problems with that tool. When it comes to providing software solutions, you have to step a bit out of that comfort zone in order to innovate and in order to provide flexibility for someone else to innovate. I started my career in Unix/C++ software engineering world years ago. Then I switched to a Microsoft shop at the end of 90s. I’ve been in the Microsoft world ever since, but I’ve shown a bit of interest in other technologies that are from the open-source community. In last few years I started digging deeper into Python, Node.js, and recently back in Java area. I have not been doing this because I am unhappy with what Microsoft had to offer, but I am rather doing it because I want to explore and find out how the open-sou...

How many times did you hear somebody say “ We don’t really do agile here ”. What does that even mean? First, the word “agile” is not a noun and you can’t do “agile”. We all forget this and we all get caught using the word “agile” as a noun. The Agile Manifesto is very good, and how some of the organizations that promote scrum approach interpreted that manifesto is just one way of looking at it. I understand why these organizations worked on converting the word “agile” from adjective to a noun. It is because you can sell nouns and you can’t sell adjectives. Think about the overall industry that is built around training people on agile methodologies and all the certifications. I have nothing against these organizations writing books and providing courses on this matter. That is all good. I encourage everybody to learn and get exposed to different types of opinions and interpretations. You can treat all that available material on agile methodology as case studies. We all know that ...

Teams ,  tech   leads ,  self - organization  and  responsibilities  are some of the keywords that I will use this in blog post. Most of this article is wishful thinking on my side, but I am being optimistic . Let me first ease into this topic by talking about the role of tech leads in the software engineering field. Be patient with me as this is all directly related to the main topic. I believe that the role of good tech leads is very often underestimated or taken for granted until they are removed from the equation and then you start realizing how much work goes into it. While the role of tech-lead is kind of stuck in between keeping project/program managers happy and working on low-level technical details, there are what I call unofficial/unwritten benefits of being a tech lead. You are in that special position as a leader where you are closest to all the activities on the floor and you can shape and improve things unofficially even though there a...

Most of the software engineering problems are solved in what I call the high-level brainstorming sessions. We basically walk into a meeting room and white-board our thoughts and come up with solutions. When things start falling apart, you better believe this happens in the last stretch of projects and it does work.  Now the issue is that we as programmers do NOT do the similar type of exercise before a line of code is written ? I typically see developers get requirements in the form of a document or a user story or in the form of walk-by requirements. The next thing I see on developers’ screens is code editors or IDEs. Is that the right thing to do? You may say that you are advanced enough and that you like to dive into coding right away, but this happens even to the best of us. We fall into this trap and rarely step back and review our habits. We have to go back to fundamentals. What did we do in school?  Professors taught us to write down our thoughts and to show what...

I have been doing software development for 19+ years, but I am relatively new to the open-source community. I learned a bit of   Python  back in 2013 and I put it on hold because I was not thrilled with the syntax and code readability as I am used to strongly-typed languages, and I picked it up again in last two years as there is something attractive about it. http://almirscorner.blogspot.com/2016/01/python-programming-series-getting.html If you are a Python expert, you should not be on this page :) Installing Python: https://www.python.org/downloads/ After installing, set the path and add: C:\Python27 NOTE: I have been running with version 2.7.x because that is still the most popular and widely used and has the biggest third-party library support. Python IDE that I like and it is most lightweight: https://www.jetbrains.com/pycharm/download/ NOTE: Install the Community edition. It is good enough. You can also use a cloud-based IDE:  http://c9...

Let’s start with a few options: (A) Be fast, risk failure and if needed quickly recover to succeed. (B) Be slow and successfully launch. Obviously the option A does NOT apply to companies that are building planes, ships, cars, medical equipment and what not. However, it does apply to a lot of other IT organizations. In option A, I am NOT talking about recklessly failing. I am talking about leading a team and trusting them  without  watching every single line of code and without introducing too many gates during the development of a project while the developers are what I call “in the zone”. As long as you have professionals on your team, you really need to use “let the baby out of the crib” methodology and allow them to fall as they are learning to walk as a team. When I say “fail”, I also don’t mean failing foolishly breaking every rule in the architecture book; that’s being foolish and not fast.  I am talking about the culture where risking normal failures ...

You may ask what the drivers of traditional manual-transmission cars and C/C++ programmers have anything to do with each other. Well, I am a software engineer and I am also a car enthusiast (aka a petrolhead in UK). I am noticing certain trends in both the car industry and the software engineering community/industry; therefore, I wanted to share my opinions. I started programming in Basic before I even owned my own computer. I remember when I first learned a for-loop in Basic, I walked over to my friend’s house and typed it up on his Commodore 64. When I was in high-school, I did more Basic (Better Basic and QuickBASIC) and also some Turing (not Turing Machine….I am talking about a language invented by University of Toronto to teach programming and it was Pascal-like). Then I switched to C/C++ and learned all about proper handling of memory and what we call “unmanaged” code these days. C/C++ were the choice if you wanted to do some low-level programming or also if you wanted to ...