HOME | Blog | YouTube | LinkedIn | About Me         || Calculators    | SoftEng/Tech Posts    | Code/Scripts

Wednesday, December 20, 2017

AWS CodeStar — this is how the cloud computing will work in the future

AWS CodeStar service ??
AWS launched two new important services:
  • * AWS CodeStar
  • * AWS Cloud9 IDE
After AWS Re:Invent, I spent some time setting up AWS Cloud9 service. I was a user of Cloud9 before Amazon acquired them. I really like the IDE and I was wondering how it integrates with the rest of the AWS services.
Then I did some more learning and setup and here are the results:
You can use AWS CodeStar service as an orchestrator/workflow that allows you to:
(1) Code an application (different templates with different languages) using AWS Cloud9.
(2) Manage the source code via AWS CodeCommit.
(3) Deploy it using AWS CodeDeploy.
All of this is managed through the AWS CodeStar dashboard. As part of creating a project within AWS CodeStar, I had an option to set it up with just one EC2 or with Elastic Beanstalk. For simplicity I chose the EC2 flavor and successfully deployed the “Hello World” Python Flask application using AWS CodeStar. After I deployed the initial version of this Python application, I went back into the Cloud9 IDE and changed some code. After doing the “git push” to the master branch, I went back to the AWS CodeStar dashboard and I was able to see in the flow that CodeCommit and CodeDeploy steps automatically started and the code changes were deployed within short time. The URL of the Python web API was provided in the AWS CodeStar dashboard and after browsing to it, or after trying it in Postman, I was able to see my changes.
Try it out because this is how the cloud computing should work; we need to focus on the business logic of our applications and the cloud providers need to take care of the rest. Obviously the AWS CodeStar is the beginning because it is focusing on setting up web applications but the setup of other peripheral services is still not included. For example, if I wanted to set up some SNS topics and SQS queues, I am not sure if the CodeStar would manage that for me.
I am looking forward to future AWS CodeStar enhancements.
Thank you for reading.
Almir Mustafic

Saturday, December 2, 2017

OWNING your sandbox

OWNING your sandbox. As software engineers we all like to work on latest technology and coding new applications. People generally don’t like spending a lot of time maintaining the code. However, in the world of microservices the owners of each microservice are very well known and defined unlike in the world of monolithic applications. That means that you own it in the true sense. You own the code. You own the QA environment. You own the Stage environment. You own the production environment and all the errors that come along with it :) On positive note, you have a lot to be proud of and you can turn it into opportunities :) You own something that is contributing your company’s customers and what you do responsibly affects the lives of many people in a positive way. Almir Mustafic

10,000 foot level view in technology

10,000 foot level view in technology: How useful is it? What can be done at this level? If the 30,000 foot level is the CTO level, then consider the 10,000 foot level as the level that software engineering managers and directors operate at. To achieve the success at 10,000 foot level, you as a software engineering manager need to dive deep into technical details, help the team lay the foundation from BOTH organizational and technical side. It is the little moves that get the team to this level. Once the team’s applications and results at that level, then you as a manager have ability to perform the high level analysis and troubleshooting without necessarily being in code on daily or weekly basis. Therefore, your ability to troubleshoot technical issues at the 10,000 foot level is a testament to the great work of your team. Go TEAM !! Almir Mustafic


AMAZON WORKSPACES. I am not sure how many of you have heard of Amazon WorkSpaces. Let me give you some information and my analysis after using it for some time. What is it? It is the Amazon’s solution to desktops in the cloud. What’s the point? Well, if you want to use a basic less powerful laptop or even use a Chromebook as your daily computer, then you will not be missing the full functionality of a powerful Windows 10 machine. For example, you can use your Chromebook to connect to your Amazon WorkSpace machine and then you get the full Windows 10 experience. The point is that it gives you the experience as if your remote/workspace Windows 10 machine is really part of your Chromebook. Where it makes the most sense is using Chromebooks to connect to your Amazon WorkSpace machine as Chromebooks with Chrome OS are fast for anything you do in the browser and they are very secure; Chromebooks are also generally cheaper than other laptops. Just a thought as an alternative to buying fully functional laptops/PCs/Macs.  Almir Mustafic

Is the grass greener somewhere else?

Is the grass greener somewhere else? I am talking about our jobs. Do you sell your house if the grass in the backyard is not green anymore?  Here are three quotes to think about: “Don’t assume that the grass is greener somewhere else; you should rather attempt watering your own grass first” — somebody “Work to live instead of living to work” — somebody “Love your job and not your company because your employer may one day say goodbye to you” — one of well respected Indian prime ministers The complicated question would be: How do you follow these three quotes and end up enjoying your life and your job? Books have been written about this. I cannot really provide you the answer, but I can definitely tell you the following after being 20 years in software engineering field professionally: If you do it to only satisfy your boss, you are doing it for a wrong reason and that enthusiasm cannot last long and it will NOT turn into positive experience. If you do it for bigger reasons, it will indirectly end up satisfying your boss and others and you will have fun. If things go bad, you have the bigger reasons to be the foundation for future.  You define for yourself what “bigger reasons” means to you. Almir Mustafic

Do-ers in your company should be taking a big role in the process implementation/improvements or at least have an important seat

Do-ers in your company should be taking a big role in the process implementation/improvements or at least have an important seat. Do-ers are connected with reality and they will tell you what works and what does not. When I say “do-ers”, I am talking about people who know what happens on the floor on daily basis. I am talking about creators, innovators, people who grind through technical problems and still speak the business language. I am not saying that do-ers alone have to drive this, but the right thing to do is to first approach them and ask them what they feel the problems are and what they feel the solutions could be. For you to solve problems, you have to have context and to have the right context, you need to be connected with daily activities on the floor. The success of your solutions is directly proportional to your contextual understanding of the problem that you are trying to solve. What worked in another company or what somebody has written in a book cannot necessarily solve your problems. In conclusion, we all need more doing. That's why I am keeping this post short and to the point as there are tasks to be done :) Almir Mustafic

Doing software development from bottom up when you need to or is this a norm?

Doing software development from bottom up when you need to or is this a norm? If somebody asked you to first build the wheels for the car before having the car at all, what would you do? First, I would question if I need to design/build 4 lug or 5 lug wheels. Then I would need to predict or ask about some details to figure out the proper offset and width for the wheels so they don’t stick outside the fenders. Now how does this car analogy apply to software engineering? First, you need to know and define the API contract. Then you would probably build a stub or mocked version of your API and you would put yourself in the shoes of the client trying to use it in cases that you can predict. Depending on the performance requirements, you may end up adding caching and other improvements. This approach is actually not that uncommon. This is actually how you would approach your team to team and microservice to microservice dependencies regardless of how well you know your consumer; it is important to maintain that discipline at the technical level but as for human communication leverage the closeness you have with other teams. Almir Mustafic

X-Factor in Software Engineering

X-factor: If we could put a number on the X-factor that defines success for you as a successful person in your line of work, then we would have a clear mathematical formula for it. X in X-factor is not as simple and quantitative as X in mathematical equations :) Almir Mustafic


SERVICE NAMES, BOUNDARIES (domain lines) and API DEFINITIONS/STANDARDS are some of many important things to achieve the enterprise-level microservice architecture and microservices. Names mean things. So you first need to properly name your services and that’s the names that you would use when talking to your teammates and clients of your services/APIs. I have a separate article on how you go about defining what a microservice is. That's titled "Micro in Microservices" on my site almirsCorner .com. Essentially, you need define the purpose and boundaries of your service. Then you get into API routes and properly defining them for each service. The goal is to keep the routes RESTful and if you run into the situation when they are not, then it should trigger you to revisit the purpose and boundaries of that given microservice. Maybe that service needs to be split into smaller services.

Thank you for reading this.

Almir Mustafic

Saturday, October 28, 2017

Architecture Diagram for ...

ARCHITECTURE DIAGRAM representing interactions of your family of microservices is one of many important things to achieve the enterprise-level microservice architecture and microservices. After going through the design and contract definitions of your APIs/microservices, your team needs to put together a single diagram that explains the interaction among microservices (owned by your team) and how these microservices interact with other teams’ microservices. This is basically the blueprint for your team’s work and this picture needs to be constantly updated as you are evolving your services. What does this give you? It gives you the big picture view and it allows you to detect good or bad patterns that you cannot see when you are deep in your code. For example, you may be able to see that you are doing too many direct API calls for something that could be done with pub/sub approach.

Almir Mustafic

P-BAR metrics in the life of agility

P = Product value
B = Bug fixing value
A = Architecture value
R = Robustness value

There are many different ways to measure the productivity of your agile teams, but certain measures get typically forgotten but they are ultimately why you are doing the work in the first place.
That's why I thought of this measuring system called P-BAR.

P for Product value and it is purposely the first letter. This is what ultimately matters. This is what your end customers benefit from. In a perfect sprint, you are always adding a lot of product value. However, the real world is not perfect and that's ok. It is ok not to have a lot of product value in sprint 0 and 1. But later you should be having sprints with the P value high.

Bug fixing value makes sense after you some number of P-value sprints and now functionality is being tested, and it is ok to have some percentage of bugs being fixed. However, if you are adding a lot of B-value in the 11th hour of the project, then it means you left all your bug discovery and/or fixing for late in the game.

Architecture value within your sprints may be high at the at the beginning sprints and occasional sprint later, but you should question it if too much of this being added closer to the end of your releases.

Robustness value measures to what degree you are developing your code to the enterprise level. This is something that should be evenly distributed throughout all sprints. It should be part of the culture and not something being done at the end.

In this article I will not get into how you measure this. You will somehow measure each value for each sprint and you can use it to detect if you are heading in the right direction and you can also capture trends/averages for overall release. At some point, I will write a full article about this.

Thank you,

Almir Mustafic

Microservice Architecture, but NOT microservice mindset?

Microservice Architecture, but NOT microservice mindset?
We are on the same team!
Let's say we as a company decide to implement the microservice architecture and we also decide to split the teams into domains for each team to own a domain (group of microservices). You may be a member of team A and I may be a member of team B and we are all on the same ship. There is a water leak in your area of the ship, but my side of the ship looks good.  What do we do? Let's help out each other because we are all members/passengers on the same ship. We are all going to the same destination :) Microservice teams were created to pave domain boundaries at the architectural level, but it does not mean that we should create boundaries among members of different domain team members. Yes, the API contracts are definitions for how our services communicate, but for the sake of final destination, we need to tear down those boundaries when it comes to approaching each other for help and proactive integration. It is beautiful to see ONE team in action especially in crunch time.

Almir Mustafic

Programming languages to teach students in high-school and university

Python-like or C-like as the language to introduce programming to students in high school and university? The question is: Do you introduce programming concepts to high-school/university students using languages that handle memory and other things for you or do you start introducing all of these concepts in languages like C that require you to understand all aspects. I will tell you what worked for me. I was introduced to programming in grade 10 using Basic programming language. There was a version called Better Basic and also Quick Basic. Then in grade 11 we learned procedural programming in a programming language called Turing (not Turing machine but a Pascal-like language developed by University of Toronto for teaching purposes). Then a year later, I started getting interested in C and C++. As you can see, I eased into the languages that introduced me to NULL exceptions and memory leaks :)
With this approach I was not overwhelmed and this set up the foundation for a fun journey in the software engineering field. However, everybody is different. What would work for majority?

Almir Mustafic

Language of Software Engineers and Scrum-master skills (quick thoughts)

Language of software engineers and skills of scrum-masters? All software developers speak the same language and that is pseudo-code :) However, there are still communication issues among software engineers specifically with other teams. That's where the role of great scrum-masters fits in. That great scrum-master does not necessarily need to be technical but he/she needs to have the skills of hearing roadblocks that engineers communicate in their technical language. I said "hearing" and hearing is not the same as listening. Listening is just a pre-requisite for hearing. Once you hear it, now you need to know how to action it and mobilize the right people. Coaching comes along with all of this, but that is a separate topic because it is also a responsibility of the tech manager. These skills separate great scrum-masters from others.
Almir Mustafic
P.S. Disclaimer: On any given day, I wear a hat of a solutions architect, engineer, scrum-master and tech manager.

Bugs in Software (quick thoughts)

Introducing bugs in your software applications? If you are a software engineer and you introduce a bug in your application, it might not be that bad.
Let me explain. The best bug you can introduce by accident is the one that fixes/heals an existing more serious problem and introduces a minor problem :) It is all about incremental improvements :)

Almir Mustafic

NoSQL (some quick thoughts)

NoSQL? If you are developing your applications for real-time interactions using NoSQL, you still need to pay attention to your data structure even though your database does not enforce it. Your model classes in your choice of programming language are your contract because that NoSQL data has to eventually end up into some form of relational database when you decide to report on it.

Almir Mustafic

Authenticity (some quick thoughts)

Authenticity - Step back and think about what makes projects successful; it is not all metrics looking good; it is about intangibles that you can't measure. It is the authenticity of certain individuals, their approaches, and how they let their energy radiate within the team. Recognizing their authenticity is the key to success.
Almir Mustafic

Saturday, October 14, 2017

Quick Thoughts — If Programming ~= 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.
In conclusion, if the act of software engineering was close to the act of programming, then you basically reached that ultimate point in developers’ eyes. Wasn’t the original goal of cloud computing to abstract things for developers so you can ideally only focus on writing code?
Almir Mustafic

Quick Tip — Building layers of cake in Software Development world

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

Quick Tip — Design for Plan A or A+B

Design for Plan A or Plan A+B?
Should you design your system with defensive Plan-B mindset or should you keep it simple thinking optimistically? I don’t think the answer is yes or no.
I am talking about the case where you prefer plan A, but the confidence level is not there yet. I think you can design it clean and simple with with hooks in your code so you can harness or feature toggle the plan B functionality. If plan A is chosen then all you need to do is clean up the hooks for the harness or feature toggle that was not needed. Nothing to lose, but you need to have the discipline to clean the unnecessary code when the dust settles down.
Thank you for reading.
Almir Mustafic

NO Feature Branches in GitHub?

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 above question is Yes, then you are not doing it the right way. Did you stub out your code or used feature toggle approach?
Thank you for reading this short article.
Almir Mustafic

Sunday, October 8, 2017

Programming, Software Engineering and DevOps — Time spent on coding?

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 technical teams are spending more and more time coding and less setting up and managing the resources in the cloud platform that the cloud platform is supposed to handle for you.
Thank you for reading.
Almir Mustafic

Saturday, October 7, 2017

Brand New programming language and one solution OR …

Brand New programming language and one solution
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 this with the 3rd programming language and train the teams on this new language?
B) Do you implement a custom solution with one of the two programming languages, but what happens to 50% of your teams that are not familiar with that language? Should they learn it?
C) Do you implement a custom solution for BOTH of the programming languages? That means that you end up with two implementations of it, but possibly one reference architecture.
At the end of the day, these are good problems to have :)
Thank you for reading.
Almir Mustafic.

Office layout and your desks?

Imagine an office environment in which you get a new desk randomly assigned to you every week.
I wonder how that would impact people’s productivity, and would that make employees walk more to their teammates? Or they would start relying more on tools like Slack, Skype for Business and similar?
I am sure it varies from employee to employee, but I wonder if anybody did any extensive studies on this.
I am curious about this because I was excited every time I moved from desk to desk during floor re-orgs. Maybe the increase of frequency would have different effects??
Almir Mustafic

POCs ??

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

Great coder != Great software engineer

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 your technical lead and software engineering manager are abstracting a lot of things for you and shielding you so you can focus on programming most of your work day.
Don’t feel rushed that you need to advance vertically in your career. You need to feel comfortable where you are, and you need to follow your gut feel. When it’s time for you expand your horizon, it is your choice to make. It is all part of becoming a great software engineer.
Now it’s time. Willingness to listen and learn from other senior software engineers, tech leads, solutions architects and software engineering managers is the key to turning yourself from a good coder into a good software engineer. This is the type of stuff you cannot easily google. You need to be patient. You have to approach it with open mind and realize that there is no book “Experience in a Nutshell” that can help you expedite this process. After some time doing things the right way becomes the second nature. In fact, it later becomes harder to NOT do things the right way.
What you will learn is:
  • * What it takes to develop and deploy robust applications at the enterprise level to production and then maintain it in production.
  • * SDLC (Software Development Life Cycle)
As you learn more and more and software engineering concepts come as second nature to you, that’s when you know you graduated and joined the club of great software engineers.
Thank you for reading. Please follow me here on Medium.com or check out my personal site: http://www.almirsCorner.com
Almir Mustafic

Knowing the limitations of an architecture is the key to preventing technical debt

Monolithic applications. Microservices.
There are different types of architectures and they all have their pros and cons. Believing that one type of architecture ONLY has advantages and no disadvantages is not going to help your team and your organization.
For instance, the microservice architecture has a lot of advantages, but if you don’t understand the microservice to microservice dependencies, it can easily get out of control and it becomes a disadvantage.
When pros and cons of a specific approach are summarized at the beginning of a given project, what gets forgotten is noting down the disadvantages and making sure that they don’t turn into technical debt for your tech teams.
It is very acceptable to have limitations in your architecture or a specific part of your system as there is not such thing as perfect architecture. We are always on the path to achieve that architecture elegance and staying on that path without reaching the perfect elegance is a norm in software engineering dynamic environment.
Now it is time to review your architecture and note down these limitations and put checks and balances around them in order to prevent these limitations turning into technical debt and spreading through the healthy components of your architecture. Knowing and controlling your limitations is the key to preventing technical debt.
Thank you for reading.
Almir Mustafic

Saturday, August 26, 2017

Yes, we software engineers do care about the business value

The perception is that software engineering only care about the low-level details and that’s where they find their motivation.
Let’s go to Day 1 out of college and you have a first professional software engineering job. It is overwhelming just to deal with the reality of having a professional job and the junior software engineers are generally all about solving the low-level technical problems and being motivated by the technology that is used in problem solving.
Later in your career as a software engineer, you learn the business better and then you start understanding what it takes to deliver an enterprise-level application to production and keep the end customers satisfied. That’s the turning point in your career where you find the motivation in:
  • * Optimizing the code and working on other geeky things
  • * Understanding how your application or your module or your few lines of code relate to the overall revenue numbers and customer satisfaction.
Then even further in your career you may get to the point where programming languages, libraries, APIs are just tools or means of getting a stable and robust application for our end customers. So your motivation may mostly come from “problem solving” in general and getting cool products to our customers.
After saying all of the above, we conclude that software engineers do care about the business value.
Thank you for reading. 
Almir Mustafic

Saturday, August 19, 2017

Commuting with a Software Engineering Series - I started this to share my experiences

We as software engineers are blessed to have opportunities to work in this field.

I am so happy to be able to share my experiences with you through my blog posts, but I also decided to post video about different software engineering topics.

Here is the introduction video of my YouTube series:


Thank you,

Almir Mustafic

Agile — Working software OVER comprehensive documentation, but no excuses after the software is working

Yes, the Agile Development Manifesto has one item that states the following:
“Working software over comprehensive documentation”
I am all for getting the software working and dealing with the issues without distracting the team with any unnecessary steps.
At the same time, I am also not a big a fan of long documentation even when you have time for documenting. Documentation is as good as it will be consumed. If nobody is consuming it because of its complexity and length, then something has to be done about it.
Single-page documents are ultimately what you should strive for. That one page should contain the overall design and concepts and also directional information which really points you to for example: a Git repo, a piece of code, or a working software that you can use to understand it, and …etc. If you start with the high-level overview and some direction, the low-level details can always be figured out if you know where to look.
This brings me back to the concept of working software and documentation. Let’s assume you and your team had some chaotic times to get the software working and you were the only person who knew how to do certain things and everybody was waiting on you to complete those tasks before other tasks could be worked on. There are two things that should be learned from this:
  • After chaotic period is over and you have a working software, you need to document what you know and set up meetings with your teammates to share that knowledge.
  • Your manager should be noticing these situations and recognizing that documentation is needed in order to prevent bottlenecks in the process of getting the crucial steps in the project.
Software engineering is an art of programming and everything else that comes along with it in order to get the software successfully delivered to production. There are three types of things regarding which your teammates or other teams could come to you asking for help:
  1. Pure information sharing: For you to share information or repeatable instructions how something is done.
  2. Opinion: For you to provide opinions how something could be designed or implemented.
  3. Advice seeking: For you to share an advice on how something should be designed or implemented.
As professionals in the software engineering field, we should be spending more and more time on items #2 and #3 and less should be spent on item #1 which is mostly repeatable and something that can be easily documented.
When you read this article, ask yourself:
  • Is there something that I only know and it is a repeatable process? If the answer to that question is YES, then please spend a bit of time just preparing a single-page high-level document with directions on how others can find low-level information. Approach your manager and share this with them and recommend further steps to share this with teammates formally or informally; sometimes simple and short videos can do wonders.
Thank you for reading. Please follow me here on http://medium.com/@almirx101
I also have some YouTube videos about software engineering at: http://www.YouTube.com/almirx101
Almir Mustafic