Tuesday, April 18, 2017

How Vlogging can wake up the creativity in you

A lot of us engineers have creativity but it is not the type of creativity non-engineer/non-analytical group of people typically have. Actually this other type of creativity is deep in us, but we need to somehow wake it up.
I did not explicitly look for ways to wake up this creativity in me; it happened in the process of doing vlogs with my family and friends, or at least I think it did. I have done YouTube videos in the past, but I have not put much thought into making them attractive. Even though they were tech videos and car videos, I could’ve applied a bit of authenticity in them to show my personality and when the personality comes through, then your videos are that much better.
My vlogs are not even public and I am having fun doing them. I spend time with my family on weekends and I figure out the story that I want to deliver and I attempt that 2–3 times during each weekend. Then I share the vlogs with my family. Creativity does not just come out if you do an occasional vlog in a month; it is that routine and daily pressure over the weekend that pushes you to be more creative and to improve. I am no Casey Neistat, but I am trying. I will keep doing it while I am having fun even though my audience with these unlisted YouTube family vlogs reaches only 30–40 views :)
What are you doing to wake up your creativity? Is it music? Is it photography? Is it art? Is it poetry? Whatever it is, go for it! Have fun.
Thanks for reading.
Almir Mustafic.

Wednesday, April 12, 2017

My fascination with Python — the journey I can’t fully explain

My career started in the Unix/C++ world in late 90s. Then I transitioned to a Microsoft shop doing C++ and then later .NET/C#. Recently I got into open-source technologies such as Java, NodeJS and Python. It’s been a fun journey over last 19–20 years doing software engineering. All software engineers should be privileged to be in the positions that we are in.
In last 2+ years I started getting into Python outside my work because I wanted to see a different perspective. I’ll be honest; even after 2+ years programming things in Python here and there, I am still not used to the Python syntax. I have been a critic of Python as I have been learning it. The curly brackets { } are very much engraved in my system and I still prefer the Java/C++/C# syntax, but there is something else about Python that has me fascinated. Maybe it is its simplicity. Maybe it is availability of different libraries that allow you to do cool things from IoT to web development. Maybe it is the cool community.
That fascination has led me to developing some interesting applications in my spare time that I also applied in my daily job. Some of those are:
  • * Production log analysis (Keeping track of existing errors/exception and detecting brand new types of errors/exceptions)
  • * API testing developers’ friendly tool/framework
  • * Microservices dependency analysis tool
  • * Tool for correcting DynamoDB data via your microservices (batch updates)
  • * Recommendations on modularizing Python code for existing Python operations code at work
I am not sure what my next application is going to be. It definitely depends on my availability at home. When I come up with an idea, I usually spend a week of evenings preparing for it and looking into the libraries that I could use. Then I usually develop the initial version over one or two weekends. One negative thing about Python is that it does not enforce disciplined and structured programming. However, if you combine your discipline from C++/Java/C# experiences with Python’s simplicity, you can develop some cool applications while writing elegant code.
If you have been in Java/C# world for a while, I recommend that you give Python a chance.
Thanks for reading this article. Please follow me and read some of my other articles in the software engineering field.
Almir Mustafic

Healthy to learn something outside your BOX

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 20 years ago. Then I switched to a Microsoft shop at the end of 90s. I’ve been in the Microsoft world until recently, but I’ve shown 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 into 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-source community has solved problems and what solutions/options are in the open-source world. This expanded my horizon a lot. It could mean that I will stay more in the open-source world or it could mean that I would take the concepts I learned and take them back into the Microsoft-shop (Microsoft is also in open-source community now) and apply them in such a way to keep things simple. Regardless, it is a win-win for me.
What are you doing to step out of your box? Try to dedicate only 1 hour per day and don’t worry about your progress. Check back in 30 days and you will see amazing results.
Thanks for reading this article. Please follow me and read some of my other articles about software engineering.
Almir Mustafic.

Scaled Agile Framework (SAFe) isn’t really scaled if you …

Scaled Agile Framework (SAFe) can help you in your organization if you use it the way it is intended. In SAFe, you have the program team that is a relatively lean team consisting of program managers, product managers and solutions architects. On the other side, the delivery teams/squads (product owners, tech team members) out-number the program team.
Therefore, SAFe is really a top-light system. What does this mean?
This means that you need to keep the delivery teams/squads constantly busy without ever falling into a situation where they are waiting for requirements/epics/initiatives to be specified and clearly defined. This can happen if the high-level requirements are produced in smaller increments and if they are groomed with a smooth flow and cadence.
So if your organization is trying to implement SAFe and you still get requirements in huge bulks every 6 months, your single point of failure becomes the program team.
Keep trying but after a while you might as well be truthful to yourselves and realize that this is not working. You are better off admitting that SAFe isn’t for me. You can still have the top part of your organization work in waterfall-ish way when it comes to defining requirements, reviewing requirements, doing the high-level technical design and planning. There is nothing wrong with that. On the other hand, the execution of the plan can be in “agile” fashion that goes well with the microservice architecture if you happen to implement this type of architecture. “Waterfall-ish” is not perfect, but it is still better than fooling yourself into believing that you are running SAFe and you are not.
The important thing is that you don’t really feel as if others are looking down on you because you are not fully implementing the “agile” methodology. What is really “agile”? I prefer to use the word “agility” because it a real noun. Agility is something you make it your own. Do an increment of work, discover what you can improve to go faster and smoother, improve it and repeat the process. Stick to basics.
Thank you for reading this article. Please subscribe and read some of my other articles.
Almir M.

Microservice Dependency Analysis Tool — Trust me; you need this

If you are reading this article, I am assuming that you are either in the process of implementing microservice architecture or you are thinking about it.
The microservice architecture has a lot of advantages and I am not going to talk about that; there is plenty of material about this topic that you can find on different blogs and also on YouTube.
The disadvantage of the microservice architecture is that it can easily get out of control because of the quantity of the moving pieces. You have to have a way of managing it. Therefore, you need the following:
  • * Capability built into the architecture to find all the configuration about microservices and their versions deployed in each environment.
  • * A tool that takes the above mentioned configuration (per environment), calculates the dependency among all microservices (and their versions) and displays this via graphs and/or or in a readable text/html format.
  • * An easy mechanism of measuring real-time calls among all microservices.
Here is a more detailed list of the tool mentioned above:
  • * Overall dependency graph between microservices
  • * Microservice A depends on the following microservices (text/html version)
  • * Microservice A depends on the following teams (text/html version)
  • * Team 1 depends on the following microservices (text/html version)
  • * Team 1 depends on the following teams (text/html version)
We talked about the WHAT; let’s talk about the WHY.
Why do you need this?
First, you need it to paint the big picture. Don’t underestimate the value of the big picture. Even if you are not doing the architecture work on daily basis, you still need to paint the big picture in the territory of your team and the teams that you are dependent on and the teams who are your clients.
You also need this to do impact analysis. The impact analysis is something you may do when you receive new requirements or when you have a problem in production (from usability or security point of view). This is where every second is crucial as your customer satisfaction is at stake and your revenue is at stake.
What about the HOW?
There are many different ways you can implement this. The most important advice is that you start simple and you can keep it simple. Build something, use it, then make it reusable and making it reusable may mean that you are buying a piece of software or a library that does this or fully building it in-house. For example, if Python and Boto3 library is something you use deploy your cloud infrastructure and deploy application code, you may choose Python as the programming language and building these type of tools is less costly and easy to evolve as you are getting more mature in your microservice architecture.
Thank you for reading this article. Please subscribe and read some of my other articles.
Almir M.

Saturday, March 18, 2017

DynamoDB Series - Do NOT design it as a Relational database

When it comes to DynamoDB tables, you need to be careful not to fall in the trap of doing relational DB design in DynamoDB's NoSQL world.

Here is my YouTube video that describes this:

Almir M.

#aws #amazon #dynamodb #database #nosql #programming #code #coding #softwaredevelopment 

Saturday, March 11, 2017

Developing Layers of Cake instead of Slices of Cake in your software engineering projects

In the microservice architecture where you have a collection of APIs that consume each other directly or via pub/sub approach, and Front End components that consume APIs, it is important that you execute the development of your features/epics and user stories in a fashion that allows product management, you and stakeholders to see progress and journeys working very early (Sprint 1 or 2).

API contracts need to be negotiated from day 1 and the stubbed version of APIs need to be developed and as the development progresses from sprint to sprint, these APIs will start to form shape.

As for the Front End, you need to have a website working (journeys working) from Sprint 1 and that website maybe using a lot of stubbed versions of APIs which is totally ok. It will evolve as you progress from sprint to sprint and less and less of functionality will be stubbed out. 

Conclusion: Develop layers of the cake instead of slices of the cake.

Almir M.

Sunday, March 5, 2017

Telling a story in SAFe — Are we doing the right thing?

Telling a story in SAFe (Scaled Agile Framework)?
As you know about SAFe, you have the program team that consists of product managers, solutions architects and program/project managers. Then you have the delivery teams with a product owner and a scrum-master in each delivery team. Product managers take the initiative/objectives from the senior leadership team and they convert that idea or objectives into a list of epics in the chosen tool. Product managers and solutions architects are supposed to meet to review these epics, to solution-ize these epics at the high level. Then they start involving the product owners and their delivery teams who would eventually create a list of user stories that would be linked to epics at the top.
On the other hand in the waterfall methodology, product managers would cook up a book of requirements in the form of a Business/Functional Requirements Document and this document would be given to technical leads and solutions architects to review, come up with the design and start executing.
I have worked within both methodologies and also in the mixture of the two. My experiences painted this picture in my mind about what really works in reality and what looks good on paper.
Let’s zoom in a bit on SAFe.
Receiving a collection of epics does not help with painting the big picture. A collection of epics does not really tell me the overall story as there is no flow to it.
Let’s use the following analogy: A writer does not tell a story by telling 12 people to write one chapter each and then combines it into a novel. The story would not radiate with anybody. The story and message would not be conveyed in the most effective way and even worse, the story would not even be told.
I think we all need to take a big step back and think about this especially if your list of epics gets translated into user stories at the delivery teams level and the final product developed is not what the author meant.
But what did the author really mean if the story was not told in a continuous flow?
There is a lesson to be learned from the waterfall approach. Yes, I said from the waterfall approach. We need to see what pieces of waterfall worked and how we can incorporate that into SAFe to make it more successful. GoodBRDs (Business Requirements Documents) and FSDs (Functional Specification Documents) written in the waterfall methodology by the product team had a very continuous flow. When you read through those documents, it felt like reading a story and as you were reading this story, you were slowly painting the big picture in your mind. Then after some BRD/FSD review sessions, that picture you painted in your mind became even more clear. As a solutions architect, having this picture in your mind is powerful; you can already start designing the overall system and it is just a matter of putting it on paper so that others can take the design and execute.
Let’s go back to the list of epics and how the overall story is NOT told by these epics and how we can improve this. I am NOT proposing that the product team writes 100-page BRDs and FSDs because those BRDs and FSDs also had some boiler-plate sections that did not contribute the to the story-telling.
However, I am proposing that the product team writes something that I call an executive story that will tell us the full story. This executive story would not be a book, but it would NOT be a 1–2 page document either because you can’t tell a story about a big initiative in 1–2 pages. This executive story would be written before any epics are written. This story would be presented to the program team who technically take a role of a book publisher. The book publishers don’t just take your story and publish it. They review it, criticize it and recommend revisions. Once this executive story is polished up and understood by the program team, then the program team proceeds with creating epics and the remaining steps in SAFe.
It is crucial that you keep adjusting the executive story as the requirements that impact the main story get introduced throughout the execution from sprint to sprint and from release to release.
So the epics are just the mechanism for getting things delivered, but the executive story is there to always reflect the current big story or the story that is being executed.
Conclusion: If somebody asks the product team to provide the summary of what the initiative / project is about, they are not going to provide somebody the list of epics to read. For example, you are not going to make your general manager read a list of epics and tell him/her to paint the picture after reading dozens of epics; that would not be right. There is an elevator-pitch summary and there is also an airplane-ride detailed version that I described as the executive story. The executive story is not only for executives; it is written with technical details geared towards the program team (solutions architects, product and project team) and it meant to tell the overall story in a continuous flow.
Almir M.

Confusion around “part-time” Scrum Master role and responsibilities

In a lot of cases, companies don’t hire part-time scrum masters or they convert a “technical lead” role into a “scrum master / technical lead” role. What really happens here is that something will have to give. Whether that’s going to be a lack of big picture planning, or impediments not being removed as fast as we would like, I am not sure. One thing for sure is that something will have to give.
Screenshot of Scrum Master roles from ScrumAlliance.org web site
In the case of technical leads taking on a part-time scrum master role, it means that the word “technical” in technical lead slowly loses its meaning. Within X number of hours on the given day, that technical lead would be doing less and less of coding and technical work. This could be good for the given technical lead if they want to grow their career into the direction of management, but it is not a good direction if you as a technical lead want to advance your career in the direction of software architecture positions. Let me rephrase this. Any temporary exposure to this type of work is good for people’s career, but I am mostly talking about long term impact exposure.
What could be possible solutions?
It all depends on your organization and what positions and it roles and responsibilities would be closer to the scrum master role in order alleviate some of this work from technical leads who are supposed to be guiding the team at the technical level and also using their knowledge to help out solutions architects and keep solutions architect in check with the reality. Development managers could help out alleviate most of these scrum master responsibilities in the cases when a dedicated scrum master role is not created. In some organization, project managers could perform that role. Maybe there isn’t one solution for all of this. Maybe on some teams, project managers do it. Maybe on some team, development managers take responsibilities.
Perhaps in some cases the technical lead is willing to also cover the scrum master responsibilities but this dialogue has to happen and no assumptions should be made. A short team help from technical leads with these responsibilities should be fine, but if a technical lead is not willing to take on these responsibilities in long term, it should NOT be looked at as a negative thing in that person’s career move within that organization. The organization should be happy that this person’s technical skills would be used to guide the technical team and that energy could also be channeled into technical innovations.
Almir M.

Wednesday, February 22, 2017

Loose coupling of Microservice Architecture

Microservice architecture is naturally loosely-coupled. If you try to tighten it, make sure you understand the impacts well.

Almir M.

Technical Lead's value

Yes, the absence of a great tech lead is felt within 2 weeks, but the real impact is felt 3-5 months after when you incurred technical debt.

Almir M.

Software Engineer & Poetry code ?

Almir M.

#code #programming #coding #softwaredevelopment #softwareengineering 

Patterns and Software Engineering Solutions - Solution-izing comes first

Don't try to look what patterns could solve your software engineering problems, but rather concentrate on coming up with solutions and if the solution ends up being one of the docmented patterns, even better :)

Almir M.

#softwareengineering #softwaredevelopment #code #programming #coding #patterns #solutionsarchitect 

DynamoDB has 1MB limit on responses. Here is an example of how to deal with it

has 1MB limit on responses. Here is an example of how to deal with it.

Almir M.


Software architecture can never be complete ...

Software architecture can never be complete. If you say yours is then your mind is not open to improvements.

Almir M.