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

https://www.youtube.com/watch?v=PWntuh1lKos




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



Disrupting the team when they reached the rhythm — Recognizing the situation to avoid it

Let’s say your company is on a journey to implement a well oiled SAFe (Scaled Agile Framework). You have the domain teams organized and each team has a manager, tech lead, a scrum-master and other technical members.
It is normal go through the initial phase of getting to know each other, how each “agile” ceremony is performed and how all your user stories tie into the bigger epic stories that spawn across multiple domain teams.
After some number of sprints, you will reach that rhythm where your domain team is very smooth in story grooming, identifying cross-team dependencies, sprint planning, developing the code and being consistent with completing the committed stories.
When the teams reach this rhythm, that’s when you should let teams enjoy the momentum and ride it as long as they can. The last thing that should be done at this time would be the introduction of any changes to how the team operates within the agile methodology. These changes could be: another way of measuring results, how you write user stories, what type of user stories are allowed, … etc.
Firstas managers, you have to be involved enough in daily activities to sense when the team reaches the peak rhythm. Then you also have to understand that introducing changes is not going to benefit the team and in fact it will do the opposite and disrupt the team. Maybe you want to change things around to better measure different dimensions within the agile methodology, but there is time where managers need to put their goals on hold for team’s sake.
The intention of these disruptions could be very valid, but if its timing is not appropriate, then you are left with negative impact on the teams and bad energy on the floor. Another important thing to point out is that not allteams reach this peak rhythm at the same time, and not all teams operate the same way; therefore, as leaders on the floor, you need to apply situational leadership skills. This is where the voice of lead engineers (tech leads) needs to be heard by their managers as they are the closest to activities on the floor. If managers are being pressured by senior leadership from the top, some negotiations need to take place in the interest of teams riding the wave of this rhythm for as long as possible.
At the end of the day, we all have good intentions, but we all have to improve in recognizing these type of situations promptly to avoid untimely disruptions.
Thank you for reading. Please follow me here or http://medium.com/@almirx101 or on Twitter: @AlmirMustafic 
Almir Mustafic




Calculating Production Delivery Date using “Agile” methodology — A flavor of story/feature/sub-feature mapping

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-levelprioritized and approved by a board before projects can be worked on. Then when they are estimated and approved, you are asked to provide project schedules with milestones and deadlines with very high-level requirements. Then some of these organizations say “let’s run these projects using the agile methodology”. What does that really mean?
What does this really mean to the delivery teams if somebody already provided the high-level estimates and basically to some degree committed when the project will be delivered?
You can still stay positive about it and concentrate on understanding the requirements and properly breaking down the project/initiative into manageable pieces and ultimately calculating the true production delivery date that you can go back to the business team with.
Let me explain how I approach this. What works for me is reading the requirements document or epics and user stories and breaking down the project into a list of features and sub-features. Then if the requirements document is written in such a way that it lists the user stories, you can easily distribute these user stories into the appropriate sub-features. If the requirements document does not explicitly list the user stories, then I would put a product owner hat on and extrapolate the user stories out of the requirements document embedded in different paragraphs.
Now that I have all the user stories under each sub-feature, I can do some high-level estimating on each story and the unit for estimation is the number of days. It is not some virtual story points and it is not the hours; it is the number of days (8h=1day).
After estimating each user story under each sub-feature, you can add up the estimates and have the list of sub-features and numbers for each sub-feature.
Now that you have the list of sub-features and estimate for each sub-feature, it is all fun after this point. It is fun because I like using Trello website to perform this mapping or pre-plan all the sprints and ultimately produce the deadline (production delivery date), because that’s what business expects from us. NOTE: In this exercise, I don’t do sprint planning at the user story level; I do this exercise of sprint pre-planning (mapping) at the sub-feature level in order to produce that deadline and to have a rough idea how each sub-feature needs to be worked on throughout the project.
What are the steps to be taken before playing the drag-and-drop game in Trello?
  • Decide on the duration of the sprint (let’s say 4 weeks). I understand that the 4-week sprint is on the longer side, but this is just an example.
  • Take the list of sub-features and estimates and break down each sub-feature into multiple sub-feature parts that are each 5 days worth of work. For example, if you have a sub-feature that has the estimate of 20 days, then you would break that sub-feature into Sub-Feature A part 1, Sub-Feature A part 2, Sub-Feature A part 3, and Sub-Feature part 4.
  • Now you are ready to plug this all into Trello backlog list and then the game of dragging and dropping starts :)
Here is how it could look like in the backlog list when you start:
Now that you have all the sub-feature parts in the backlog, it is time to gauge what the optimal number of resources is. Let’s do some simple math.
  • 6 resources
  • 4 week sprints (20 working days)
  • if everybody is a robot, then the team should be able to chunk away 120 days (6x20) out of the estimates. Yeah right !!! With all the meetings and interactions between teammates, a reasonable number to achieve in each sprint would be 60–80 days worth of work. If each part of the given sub-feature is equivalent to 5 days worth of work from the estimates, then you should be able to drag and drop 10+ of those parts into a given user sprint.
You as the technical lead and technical project manager know best how each sub-feature is related to each other and you are deciding those things as you are loading each sprint with the list of sub-feature parts.
Here is how it may look after going through this exercise. It looks like the duration of the project would be around 14 weeks (3.5 months). If you know what the start date is, then you can easily calculate the production launch date. You also know when you need to start each sub-feature and when each sub-feature is supposed to be completed. That can help you point out some major milestones to your senior management team. 
You are done. Provide your boss the duration of the project, major milestones and the production launch date that you can achieve based on these high-level estimates.
What’s next?
Well, now you need to share this with the delivery team and help out the team do proper sprint planning at the user story level by using this sub-feature plan. I happened to use Trello just for the purposes of “sub-feature” planning, but when it comes to sprint planning at the user-story level, your team will need to use whatever tool your company approved.
Good luck and have fun.
Thank you for reading this article. Please follow me here on almirsCorner.com or check out my articles on Medium.com/@almirx101 or if you prefer watching software engineering videos, you can check out my YouTube channel: http://YouTube.com/almirx101
Almir Mustafic