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
I also have some YouTube videos about software engineering at:
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 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 or check out my articles on or if you prefer watching software engineering videos, you can check out my YouTube channel:
Almir Mustafic

Sunday, July 23, 2017

Innovation Speed — Should you avoid applying UI if you can?

A lot of times, as the technical team in a company, you get pressured to build a self-service tool so that business/product-team can perform their configuration and content changes without involving the tech team.
Should you just build what the business/product teams requested or should you justify why this should not be done in the interest of both the business and the tech team and ultimately in the interest of your end customers?
To question the requirements from your product/business teams, you need to have very good justifications and counter proposals. In a good work environment, the requirements should not just come from business and be executed by the tech team. It should be a two way conversation. The perception is that the tech team just wants to deal with technical details, but the reality is that the tech team wants to be involved at the idea phase before the requirements get baked and turned over for design and implementation. Early in my career I was happy with just focusing on technical details and enjoying the process of solving problems through coding. Then later I realized that my motivation comes from knowing what the business team wants to achieve and for me it meant that I was able to translate that to a much better working software.
Let’s use the Price & Product Configuration and its UI tool as an example. This subject is very dear to me and I have certain vision that I would like to share in order to get to the essence of this article.
Let’s assume you built a set of microservices and database structures behind each service to support the following capabilities:
  • * Creating offers (no UI but configurable) and specifying the price
  • * Creating benefits/features (no UI but configurable)
  • * APIs that allows you fetch offers and query offers in order to decided what offer(s) to display to customers
  • * API that allows you fulfill offers and ultimately create customers’ subscription records
Let’s say these feature are very stable in production, but you still need to continue to iterate and build new capabilities and enhance existing capabilities for the business requirements that are geared towards the end customers.
At the same time you maybe getting business requirements that are are about the self-servicing of these features for internal customers (your product and business team). These requirements are all about above mentioned capabilities of microservices and introducing some UI tool that allows the business team to perform price and product configuration (creating offers, creating benefits, configuring and changing prices for offers, …etc).
The goal purely looking from the tech team’s angle is to have agility and to innovate. When you introduce UI tools on top of your evolving microservices, then it really slows down your ability to innovate and adapt quickly. Why does the building of a UI tool slow you down? Think about the possible impacts if you change the underlining functionality and structure of your microservices:
  • * You will also need to change the UI to accommodate for these changes
  • * You will need to possibly train the users of UI if the changes are drastic enough
  • * And you will need to roll this out without causing too much disruption.
All of this requires a lot of effort and coordination. This effort and coordination is acceptable after you have a mature product in production, but it is too much overhead if you are still rapidly evolving.
If you have a choice, you really need to consider delaying any self-service UI tools for your business until the data structure and microservices for your data structures are mature enough; otherwise, you would be just slowing down the delivery of new features in these microservices for end customers even though the tech team can deliver all the changes that the UI tool would do for business users by just making application config changes. This is a very good alternative during this crucial innovation phase.
Therefore, as the tech team you need to be able to convey this message to your business and propose investments into the capabilities of these microservices for end customers before building a self-service UI tool. But at the same time, you need to provide to business some visibility to the configuration from these microservces so they can better visualize what what capabilities they have so far. That could be just a BETA version of some simplistic UI tool that is about purely REAL-ONLY information . If it is a “read-only” version of this tool, then the effort is much lower and there is less to consider from the security point of view. Overall, I think this is a good compromise for some amount of time to keep the agility at a high level and to keep the innovation going.
Let’s go back to the days when Google released the beta version of GMail. They kept the beta version for quite some time and they informed users that they don’t have any obligations to support customers requests. Why did they do this? They did it because they did not want to slow down the innovation of GMail in its early days by introducing the formal UI; that’s why kept it as a beta version. I am not saying that you should be doing this for as long as Google has done it, but the overall conclusion is the same.
In conclusion, consider delaying building the official self-service UI tools for your product/business users in order to keep the innovation and agility at a high pace during crucial phase in the evolution of your microservices and data structures/configurations.
Thank you for reading this article. Please follow me here on or check out my personal blog:
Almir Mustafic

Code to get around the process OR Code it right and improve your deployment methodology and the process

Code is just code. Process is just process. However, when you combine the two, they impact each other in ways that they should not.
Let’s assume you built a platform for your team. Then the process came later and slowed down things but kept things as stable as possible. Then software engineers realized that they can follow the process and do the development in such a way that they can go quicker through this process. I am talking about writing code that is so over-configured that it actually allows you to deploy changes to production quicker just because it is a configuration change that you are deploying. When your platform is over-configured, the weight of a configuration change is so huge that you can introduce functional changes to the degree that makes you wonder if you are adding so much risk to the business because you are taking a shorter path in the process workflow. The risk is there because software engineers don’t feel comfortable making these heavy-weight configuration changes and nobody likes doing any change in the engine of the code that drive this heavy configuration.
This really smells as coding to get around the process. Is this right?
I am all about automating the process, but when it comes to over-configuring your code just for the purposes of getting around or going quickly through the process, it is totally wrong.
As a software engineer or a technical lead, every time you find yourself thinking how to adjust the code to make it very configurable to get around the process, you should ask yourself the following questions:
  • How can I help automate or implement the continuous integration in such a way that I can do the right thing in my code. The right thing could be that you actually make a code change that requires a compilation, build and deploy and the code instead of trying to make it configurable and complicating your codebase and increasing maintenance costs.
  • How can I work with the Change Control team and improve the SDLC/PDLC process in order to make it jive with the platform/framework you have implemented in your company.
It is ok to have a simple code change instead overcomplicating the code to make it configurable so that you change ends up being a configuration setting.
In conclusion, it is important that you design your process at the same time you are building your new platform. That’s how they compliment each other better. As for software engineers, please don’t code to get around the process. Please code it right and identify incremental changes how you can improve your software deployment approach.
Thank you for reading. Please follow me here on or check out my personal blog:
Almir Mustafic

Sunday, July 9, 2017

Figure out a solution before you open a book of design patterns — Quick Advice

A lot of times software developers get caught in the situation where they are reaching for the book of design patterns to see how they could solve a specific problem.
Programming languages are rich enough to help you solve different problems and a lot of programming languages and its frameworks can be used to easily implement different design patterns. However, when something like this is readily available to you, you need to have enough discipline NOT to reach for it right away.
What do I mean by this?
It is important to first truly understand what problem you are trying to solve. Work with your product owner and make sure that requirements are true business requirements without inclining any type of implementation. Once the requirements are in good shape, then you know what problem you are trying to solve.
Then you need to work out different solutions for that problem. This is where you would use your overall software engineering experience. You should NOT open a book of design patterns and look for what could solve your problem, but you would rather work out a solution and then if it happens to be one of the known patterns, the implementation of it would be that much easier.
Please think about this any time you are presented with a problem to solve.
Thank you for reading. 
Almir Mustafic

Friday, July 7, 2017

Plotting graphs with Python — Simple example

As plotting graphs is something that my oldest kid started doing in school, I decided to finally spend some time doing it in Python. This article is about the basics, but I will also later get into the calculations of medium, mean, mode and other more complex concepts of plotting graphs using mathematical formulas.
Here is an example that shows you the following:
  • * takes a list or more lists and plots it on the graph
  • * plotting of points on the graph with or without connecting it into lines
  • * applying the labels on the x-axis and y-axis
  • * applying the overall title on the graph
  • * adjusting your scale based on what type of data you have for each axis
Install the following libraries before running the code below. By the way, the example is written for Python 2.7.x:
pip install matplotlib
pip install matplotlib-venn
Here is the example that you can play with as it has a command-line menu that allows you to choose which type of graph you want:
__author__ = 'Almir Mustafic'

from pylab import plot, show, title, xlabel, ylabel
from pylab import legend
from pylab import axis

def main():
    print("main program")
    while True:

        choice = raw_input('Pick from the menu? ')

        if choice == '1':
        elif choice == '2':
        elif choice == '3':
        elif choice == '4':
        elif choice == '5':
        elif choice == '6':
        elif choice == '7':
        elif choice == 'q':


def print_menu():
    print('1. Plot a few points WITHOUT dots for the given point and connect as line')
    print('2. Plot a few points WITH dots for the given point and connect as line')
    print('3. Plot a few points WITH dots and WITHOUT the LINE')
    print('4. Plot Ladera Ranch town temperature with DOTS and LINE and NO X-Axis specific range')
    print('5. Plot Ladera Ranch town temperature with DOTS and LINE and X-AXIS range specified')
    print('6. Plot Ladera Ranch averages in 1996, 2006 and 2016 for 12 months. 3 graphs')
    print('7. Plot Ladera Ranch averages - Adjust AXIS based on min and max')
    print("q. QUIT")

def plotting_example01():
    print("Plotting example 1............")

    x_numbers = [1, 2, 3]
    y_numbers = [2, 4, 6]

    # Plot the line WITHOUT dots for the given points
    plot(x_numbers, y_numbers)

def plotting_example02():
    print("Plotting example 2............")

    x_numbers = [1, 2, 3]
    y_numbers = [2, 4, 6]

    # Plot the line WITH dots for the given points
    # Markers can be 'o' or '*' or 'x' or '+'
    plot(x_numbers, y_numbers, marker='o')

def plotting_example03():
    print("Plotting example 3............")

    x_numbers = [1, 2, 3]
    y_numbers = [2, 4, 6]

    # Plot the line WITH dots and WITHOUT LINE
    plot(x_numbers, y_numbers, 'o')

def plotting_example04():
    print("Plotting example 4............")

    ladera_temp = [53.9, 56.3, 56.4, 53.4, 54.5, 55.8, 56.8, 55.0, 55.3, 54.0, 56.7, 56.4, 57.3]

    # Plot the line WITH dots and the LINE
    plot(ladera_temp, marker='o')

def plotting_example05():
    print("Plotting example 5............")

    ladera_temp = [53.9, 56.3, 56.4, 53.4, 54.5, 55.8, 56.8, 55.0, 55.3, 54.0, 56.7, 56.4, 57.3]
    # years = range(2000, 2013)
    years = range(2000, len(ladera_temp) + 2000)

    # Plot the line WITH dots and the LINE
    plot(years, ladera_temp, marker='o')

def plotting_example06():
    print("Plotting example 6............")

    ladera_temp_1996 = [53.9, 56.3, 56.4, 53.4, 54.5, 55.8, 56.8, 55.0, 55.3, 54.0, 56.7, 56.4]
    ladera_temp_2006 = [43.9, 66.3, 46.4, 63.4, 34.5, 75.8, 46.8, 65.0, 75.3, 64.0, 56.7, 46.4]
    ladera_temp_2016 = [23.9, 26.3, 36.4, 33.4, 44.5, 55.8, 66.8, 75.0, 65.3, 54.0, 46.7, 36.4]

    months = range(1, 13)

    # Plot the line WITH dots and the LINE
    plot(months, ladera_temp_1996, months, ladera_temp_2006, months, ladera_temp_2016, marker='+')

    # OR you can plot separately like this and the final show() method will know that it needs to plot everything that is queued up.
    # plot(months, ladera_temp_1996, marker='o')
    # plot(months, ladera_temp_2006, marker='o')
    # plot(months, ladera_temp_2016, marker='o')

    # Apply the legend to tell the graphs apart
    legend([1996, 2006, 2016])

    # Apply the TITLE, X-axis and Y-axis label
    title('Average monthly temperature in Ladera Ranch town')
    ylabel('Temperature in F')


def plotting_example07():
    print("Plotting example 7............")

    ladera_temp_1996 = [53.9, 56.3, 56.4, 53.4, 54.5, 55.8, 56.8, 55.0, 55.3, 54.0, 56.7, 56.4]
    ladera_temp_2006 = [43.9, 66.3, 46.4, 63.4, 34.5, 75.8, 46.8, 65.0, 75.3, 64.0, 56.7, 46.4]
    ladera_temp_2016 = [23.9, 26.3, 36.4, 33.4, 44.5, 55.8, 66.8, 75.0, 65.3, 54.0, 46.7, 36.4]

    months = range(1, 13)

    # Plot the line WITH dots and the LINE
    plot(months, ladera_temp_1996, months, ladera_temp_2006, months, ladera_temp_2016, marker='+')

    # OR you can plot separately like this and the final show() method will know that it needs to plot everything that is queued up.
    # plot(months, ladera_temp_1996, marker='o')
    # plot(months, ladera_temp_2006, marker='o')
    # plot(months, ladera_temp_2016, marker='o')

    # Figure out AXIS X and Y min and max and set it for the graphs.
    xy_tuple = axis()   # returns tuple (x-min, x-max, y-min, y-max)
    my_ymin = xy_tuple[2]

    # Another way to set X-min, X-max, y-min, y-max
    # axis([xy_tuple[0], xy_tuple[1], xy_tuple[2], xy_tuple[3]])

    # Apply the legend to tell the graphs apart
    legend([1996, 2006, 2016])

    # Apply the TITLE, X-axis and Y-axis label
    title('Average monthly temperature in Ladera Ranch town')
    ylabel('Temperature in F')



if __name__ == "__main__": main()
Here is the command-line menu that you should see when you run this Python code:

For example, if you select option 6 (graph that uses a lot features summarized above), then you will the following graph pop up:

If you select option 7, then you will see how the scaling on the graph is adjusted explicitly through code:

Almir Mustafic

Sunday, July 2, 2017

Fractions in Python

Doing fractions or math using Python is not something new, but I was anxious to try it out because my kids have been learning fractions in school. So I wanted to be that super dad who can solve the fractions very quickly or at least I could use it to verify their homework.
Here are samples that you can copy and paste into your text editor and try out without needing to do any modifications. These examples are tested in Python 2.7.13 in Mac OS.
Here are some basic examples setting fractions and doing some basic operations. There is also exception handling for zero division:
__author__ = 'Almir Mustafic'

from fractions import Fraction

Playing around with fractions

def main():
    print("main program")


def set_fractions():
    print("set_fractions method ..............")

    f1 = Fraction(3, 4)

    f2 = Fraction(8, 4)

def fraction_operations():
    print("fraction_operations method ............. ")

    fsum = Fraction(3, 4) + Fraction(6, 4)

    my_float = float(fsum)

def input_and_calculate_fractions():
    print("input_and_calculate_fractions method ..............")

    # Enter for example: 2/3
    # Try entering 2/0 to see how it tells you that it is invalid
        a = Fraction(raw_input("enter a fraction: "))
    except ZeroDivisionError:
        print("Invalid fraction")


if __name__ == "__main__": main()
Here is a more complete example that allows you to interact with it. You can perform add, subtract, multiply and divide.
__author__ = 'Almir Mustafic'

from fractions import Fraction

def main():
    print("main program")

def perform_fraction_operations():
    while True:

            fraction01 = Fraction(raw_input('Enter fraction: '))
            fraction02 = Fraction(raw_input('Enter another fraction: '))

            my_operation = raw_input('Perform one the following operations: Add (A), Subtract (S), Divide (D), Multiply (M) : ')


            if my_operation.capitalize() == 'ADD' or my_operation.capitalize() == "A":
                add(fraction01, fraction02)
            if my_operation.capitalize() == 'SUBTRACT' or my_operation.capitalize() == "S":
                subtract(fraction01, fraction02)
            if my_operation.capitalize() == 'DIVIDE' or my_operation.capitalize() == "D":
                divide(fraction01, fraction02)
            if my_operation.capitalize() == 'MULTIPLY' or my_operation.capitalize() == "M":
                multiply(fraction01, fraction02)
        except ValueError:
            print('Invalid fraction entered')
        except ZeroDivisionError:
            print("Zero division fraction. Do NOT do this :)")


        answer = raw_input('Do you want to exit? (yes) for yes or just press enter to continue: ')
        if answer == 'yes' or answer == 'y':

def add(f1, f2):
    print('Result of adding {0} and {1} is {2} '.format(f1, f2, f1+f2))

def subtract(f1, f2):
    print('Result of subtracting {1} from {0} is {2}'.format(f1, f2, f1-f2))

def divide(f1, f2):
    print('Result of dividing {0} by {1} is {2}'.format(f1, f2, f1/f2))

def multiply(f1, f2):
    print('Result of multiplying {0} and {1} is {2}'.format(f1, f2, f1*f2))


if __name__ == "__main__": main()
Thank you for reading. 
Almir Mustafic