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

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

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

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

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

Most of the software engineering problems are solved in what I call the high-level brainstorming sessions. We basically walk into a meeting room and white-board our thoughts and come up with solutions. When things start falling apart, you better believe this happens in the last stretch of projects and it does work.  Now the issue is that we as programmers do NOT do the similar type of exercise before a line of code is written ? I typically see developers get requirements in the form of a document or a user story or in the form of walk-by requirements. The next thing I see on developers’ screens is code editors or IDEs. Is that the right thing to do? You may say that you are advanced enough and that you like to dive into coding right away, but this happens even to the best of us. We fall into this trap and rarely step back and review our habits. We have to go back to fundamentals. What did we do in school?  Professors taught us to write down our thoughts and to show what...

Let’s start with a few options: (A) Be fast, risk failure and if needed quickly recover to succeed. (B) Be slow and successfully launch. Obviously the option A does NOT apply to companies that are building planes, ships, cars, medical equipment and what not. However, it does apply to a lot of other IT organizations. In option A, I am NOT talking about recklessly failing. I am talking about leading a team and trusting them  without  watching every single line of code and without introducing too many gates during the development of a project while the developers are what I call “in the zone”. As long as you have professionals on your team, you really need to use “let the baby out of the crib” methodology and allow them to fall as they are learning to walk as a team. When I say “fail”, I also don’t mean failing foolishly breaking every rule in the architecture book; that’s being foolish and not fast.  I am talking about the culture where risking normal failures ...

With the trend of front-end Javascript frameworks, there is more and more logic pushed to the client side in the Javascript code. With all this comes more responsibility when we talk about security. It requires a lot of discipline. Front-end and back-end (API) developers need to work very closely together so that secure information is not revealed in the Javascript code. Almir Mustafic

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-level ,  prioritized  and  approved  by a board before projects c...

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