Software Engineering Blogger

Imagine the world in which feature branches don’t exist. Imagine the world where you don’t delay your code integration (code merges) until 11th hour and you deal with it on daily basis. Imagine the world of just main trunk development in GitHub and development mindset and development capabilities that allow your teammates to see your code sooner rather than later. Pay me now or pay me later is what one of my friends has been saying. Yes, this goes against what everybody is doing out there, but it is worth exploring. It requires the right mindset and technical skills. It ultimately boils down to the following advice that I always give to fellow developers: * Regardless of what branch you are in, when you check in or commit your code changes, pretend that these changes will go into production right away. Then ask yourself a question if my code will negatively impact customers and will it change the customer experience if product team wasn’t intending to do so yet. If the answer to a...

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...

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...

Imagine the world of software architecture where every POC becomes a production software without changes. That’s one extreme. Now imagine the opposite where no POCs get done and no free innovation happens and everything has to be 110% planned and build perfect from day one. If you and your team can take the good aspects of both extremes and combine into one nice approach, then you will innovate and that innovation will turn into enterprise worthy software. 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 ...

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...

Great coder != Great software engineer How do you change that sign into an “=” sign? As a software engineer out of college, your initial goals are to get use to the professional working environment. Once you get passed that first hurdle, then it is all about the programming or coding skills. You want to improve your .NET C# skills or Java skills or NodeJS skills or Python skills or database skills. You want to learn the frameworks around these programming languages better and you want to learn different ways to optimize your code and apply different design patterns in your implementations. These are great skills to have and in a lot of cases required skills to have. The most important thing is that you are enjoying what you are doing. At this point you have reached that level that will give you the right to label yourself as a great coder or a great programmer. However, there is still more to go. At this time your main focus is programming and you may be lucky that ...

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 ...

With the trend of front-end Javascript frameworks, there is more and more logic pushed to the client side in the Javascript code. With all this comes more responsibility when we talk about security. It requires a lot of discipline. Front-end and back-end (API) developers need to work very closely together so that secure information is not revealed in the Javascript code. Almir Mustafic

Manifesto and the role of tools within the world of Agile Software Development? Part 1 of the manifesto: “ Individuals and interactions over processes and tools ” Are the tools we use to support our Agile Software Development ruining the actual agility on day-to-day basis? Are these tools affecting the chemistry of the team? Are the companies that sell these tools feeling the pressure to innovate and to keep owners and stockholders happy?  Then the innovation turns out to be tipping the manifesto statements to the right side  (contradicting the manifesto) because the decision makers in companies who buy these tools  may  want the tools that are all about tracking, measurements, and reporting without thinking how useable these tools are for teams on daily basis. I am putting a lot of questions in this post and I am not going to necessarily give you answers to these questions. This post is more about having you think about these things and realizing whether ...

Estimating projects/initiatives is not easy if you don’t have a right approach. You can be in MS Project land trying to figure out little details, but those details change and then you are stuck maintaining schedules in MS Project. You spend a lot of time tweaking the tool instead of proper planning. A lot of companies are trying to change to use the “Agile” methodology and I am putting the word “Agile” in quotes because there is no company out there that is following exactly what you are taught in ScrumMaster courses and SAFe courses. That means that companies sooner or later end up doing  what works for them  and that could be an approach that belongs somewhere on the line between Waterfall and Agile; for some companies closer to Agile, and for some companies closer to Waterfall. For example a lot of companies get a list of projects/initiatives that need to be  estimated at high-level ,  prioritized  and  approved  by a board before projects c...