Software Engineering Blogger

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

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

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

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

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

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

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

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.

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

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

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

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

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

Software Engineering… Programming is an act of giving a machine some instructions so it can perform things repeatedly. Software engineering is an act of programming and everything else that goes along with it in order to deliver enterprise software to production. Within software engineering, the more time you spend coding your applications and less worrying about DevOps things and processes, the better for you. Make sure you are heading in the right direction. Let’s say you use a cloud platform to run your applications. The whole point of a cloud platform was to abstract things for developers in order to spend more time coding applications and less worrying about how to set up the resources in the cloud platform. So if you are hiring a lot of DevOps experts, then it means that the platform itself did not abstract the cloud enough. In conclusion if the act of software engineering is close to the act of programming, then you basically reached that ultimate point where your techn...

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

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

I had to remind myself about this as I worked on Unix/Linux platform a long time ago and having been in Microsoft shops for many years did not help either :) If you want your environment variables (being set up by another script) to be properly set up in the context of the window where you are running the script, you have to  run the script with a dot and a space in front of it  as shown in the screenshots below. Screenshot of vim editor showing you the content of setup.sh script: Executing the script in bash window and then verifying if an environment variable is set up: Thank you for reading. Almir Mustafic

Code kids? Let me start by saying that I was NOT a code kid. Generally speaking a code kid is a kid that starts programming at early age and by early age, I am talking about 6 to 12 years old. I was good in math and science, but the first time I was exposed to programming was in grade 8 which is considered late by code-kid standards :) In grade 8, I was writing code on paper and asking one of my friends to borrow his Commodore-64 to see what it runs. I was excited to see my first for-loop working. When I really got into it, I was in grade 11 and 12. I enjoyed it and I have been deep in this world ever since. There is a level of satisfaction that programmers get when they figure out a problem after hours of troubleshooting. It is hard to explain until you experience, and you also can experience it. Does every kid need to end up working as a software developer? No, they don’t, but being introduced to programming in early days is very important for exposing kids to different ...

When you have a problem to solve, what is the most typical way to approach it? Everybody is different, but most of us try to stay within our comfort zone because that’s what makes us feel more stable or more secure. We have one tool and we try to solve all the problems with that tool. When it comes to providing software solutions, you have to step a bit out of that comfort zone in order to innovate and in order to provide flexibility for someone else to innovate. I started my career in Unix/C++ software engineering world years ago. Then I switched to a Microsoft shop at the end of 90s. I’ve been in the Microsoft world ever since, but I’ve shown a bit of interest in other technologies that are from the open-source community. In last few years I started digging deeper into Python, Node.js, and recently back in Java area. I have not been doing this because I am unhappy with what Microsoft had to offer, but I am rather doing it because I want to explore and find out how the open-sou...

How many times did you hear somebody say “ We don’t really do agile here ”. What does that even mean? First, the word “agile” is not a noun and you can’t do “agile”. We all forget this and we all get caught using the word “agile” as a noun. The Agile Manifesto is very good, and how some of the organizations that promote scrum approach interpreted that manifesto is just one way of looking at it. I understand why these organizations worked on converting the word “agile” from adjective to a noun. It is because you can sell nouns and you can’t sell adjectives. Think about the overall industry that is built around training people on agile methodologies and all the certifications. I have nothing against these organizations writing books and providing courses on this matter. That is all good. I encourage everybody to learn and get exposed to different types of opinions and interpretations. You can treat all that available material on agile methodology as case studies. We all know that ...

Teams ,  tech   leads ,  self - organization  and  responsibilities  are some of the keywords that I will use this in blog post. Most of this article is wishful thinking on my side, but I am being optimistic . Let me first ease into this topic by talking about the role of tech leads in the software engineering field. Be patient with me as this is all directly related to the main topic. I believe that the role of good tech leads is very often underestimated or taken for granted until they are removed from the equation and then you start realizing how much work goes into it. While the role of tech-lead is kind of stuck in between keeping project/program managers happy and working on low-level technical details, there are what I call unofficial/unwritten benefits of being a tech lead. You are in that special position as a leader where you are closest to all the activities on the floor and you can shape and improve things unofficially even though there a...