Software Quality

As you may know, I’m working on an open source project called Visual MASM which is an IDE to create assembly applications for Windows just as easy as the Delphi or Visual Studio IDEs provide. Well, at least that is my goal.

I was looking back on why I want to create a commercial application in the Real Estate industry using my very own assembler IDE and was reading what I wrote about using assembly in the first place: Why Assembler?

There are so many languages and tools available today in order to program a solution. I have used almost all of them in the past 32 years of programming. Why on earth use assembly for Windows? For a clear business reason, Windows “owns” the world wide market and is used in over 90% of computers as of today. Never mind Linux, MacOS, etc. I mean, Windows “owns” it. Period. It makes total sense to develop for Windows when you create a commercial solution.

The fact that Windows owns the market; however, is still secondary to my motivation to create a commercial application for Windows using the assembly language. The main reason is really: Software Quality.

Quality in general, in my opinion, means paying attention to every detail. Because one pays attention to every detail, you are forced to make many decisions. As you abstract into higher languages, these decisions have been made for you. Because of this, you are no longer able to make detailed decisions. In order to pay attention to the detail of software quality, you have passion to follow through with it. Being able to make these detailed decisions also offers freedom and control of the creation process. That’s the ultimate power of high, software quality. You must have control in order to make software quality decisions.

So, paying attention to detail with passion is equivalent to high software quality. It is that simple.

 

Advertisements

How to be a great programmer

I have been programming since I was 15 at 1985 starting on an Amstrad CPC 464 on 8-bit Z80 processor at a whooping 4 Mhz. The programming language used was Locomotive Basic for the Z80 processor. This is my first exposure to actually tell a computer what to do, and it did it by coding this:

10 Print "Hello"
20 Goto 10

It printed “Hello” on the screen and kept going. These simple lines woke up my passion and my amazement of the computer and it’s software. The computer did what I just told it to do, over and over. That was 32 yeas ago and I still love creating software, love seeing creativity transformed into something useful and beautiful at the same time.

The reason I’m telling you this is because I want to set the stage of what I have learned over the past 32 years on how to be a great programmer if you so desire. What I’m about to share with you are my own experiences and opinions.

Here are a few things that you either have or will gain over time as a great programmer:

You care

As with everything in life, if you care for something, you give it special attention. Now, programming a computer needs your special attention already because the computer will not allow for any mistakes simply because there are no gray shades. What I mean by that is that the computer is absolute, true or false. When you care, you pay special attention to the software you program. What does that mean? You care how you compose your pieces of code in whatever programming language you use. Is your code legible? Can you understand your code 6 months from now? What does the architecture look like? Have you even thought about it? How does any data flow between your methods and functions? Where does it start and where does it end? Can you follow the money within the programming code? Do you care enough to rename your variables and functions to something more understandable after requirements change? Do you care enough to reduce any technical debt meaning do you care enough to simplify your code to make it easy to maintain? Do you care enough to remove dead code? Do you care enough to be open for new ideas on how to do things differently than what you are used to? When you care, you pay attention to the smallest details. You pay attention to quality on what you program into the computer.

You love creating

A writer creates a book by composing letters and words in such a way that produces interesting stories. A writer would use modern tools such as a computer with a great word processor or maybe even an old fashioned typewriter. The tools a book author would use are the means to an end. The creative part is all in the authors head. The art is the intuitive process of creation that is unique to the author. The very same thing can be said for a great programmer. When you start coding, you are composing instructions for the computer to execute. The creative part is on “how” these instructions are executed in such a way that produces software, the end product. How satisfying is it when a customer/user tells you “I love this software”. When a customer tells me that they love my product, it makes my day and this is exactly why I love creating great software. Every programmer wants to be recognized in some form or another for his or her creativity to solve a problem. After all, programmers are problem solvers. We solve problems with our code. Our code is our magic dust that erases issues and makes people happy. How cool is that? How cool is it to start from an idea to something tangible that people can use? Doesn’t every creator want their creativity to be seen, used, and acknowledged? You have the power to change the world with your creativity.

You love problem solving

Programmers are problem solvers. That’s it. I love solving problems with a creative approach. The way you attack problems can be in different ways. It becomes even more interesting when you solve problems that are considered not the norm. You think out of the box. Many times, you do not have to re-invent the wheel because somebody has already solved a problem in the past in some form or another. If that is the case, take a close look how the problem was solved. Would the solution fit on what you are trying to problem? Can you adjust the solution to fit your needs? Can you improve it? Or, can you come up with a unique way to find a solution to a problem? How do you approach the problem? I find solutions to problems in all kinds of places, while taking a shower, while shaving, while starring into the sky, while playing a computer game, etc. When you get ideas to solve a problem, it is one of the super exciting moments when it happens. My point is that your solutions can come anytime. It does not matter if you are sitting in front of the computer or not. You should be open to think and analyze about problems no matter where you are. Give these moments a chance hen they come, explore it further and be open to whatever idea will come to mind.

Stay motivated

You will not be able to create fantastic code if you are not motivated. You have to be motivated and enjoy programming in order to produce some amazing creations. You have to get your juices going. For some, like me, you have to be in the “zone” for some crazy creativity to come out of your noodle. For me, listening to music while programming get’s me into the right mood and kick of some “zone” explorations. So, if you are motivated on one day, how do you stay motivated the next day? One thing I do that has worked for me for many years is that I “carry over” motivation to the next day. The way I do this is as follows: when you work on a particular challenge to solve a programming problem and you eventually find a solution to it, do not implement the entire solution the same day even if you could implement it within minutes. Don’t do the whole implementation. Keep some of the implementation for the next day. When you do this, you can start programming the next day and “re-ignite” that motivation to complete it. What will happen is that you are now on a roll and you will be able to pick up other challenges easier and keep the momentum for that day. This little trick of “carry over” has helped me many times of the years. It unleash some energy the next day even though you may have not felt like it to program at all.

Be willing to learn

A great programmer NEVER stops learning on how to program in different ways even how to program in different languages. Study other peoples code when you have a chance. This will give you an insight of somebody else’s line of thinking to find a solution. This might show you some ideas that you were not thinking about before. Be willing to learn from others, always. Don’t think you know it all. There is no such thing. There will always be somebody else you knows a lot more than you do. So, be willing to learn from anybody. It does not matter if the other programmer is a junior or a senior programmer. Stay open to learn especially “how” they achieved a certain solution.

Learn assembly programming

Yes, you read correctly. Learn how to program in assembly. I know there are tons of high-level languages that you can learn as a programmer such as Java, C#, C, C++, Delphi, etc. However, trust me when I tell you: “You will be a better programmer when you learn how to program in assembly”. You will have an edge over somebody who does not program in assembly. Believe me. What programming in assembly will teach is invaluable compared to any other high level programming language. You will truly appreciate the power of the computer. You will be able to see into the insights of the computer. You will be on a higher level of technical excellence when you know how to program in assembly. I personally love Microsoft’s Macro Assembler (MASM) for Windows over all the other assemblers for many reasons. One reason is simply that Microsoft has pored a huge amount of resources over the past 36 years into MASM. MASM was created in 1981 and no other assembler has received this much attention, ever. Microsoft maintains MASM today. When you learn to have absolute power of the computer and with absolute freedom to create ANYTHING you want with assembly, you will gain a level of insight that is hard to describe. In many ways, assembly is actually easier than many high level languages. It is absolutely fascinating to be able to directly manipulate a CPU register. It is fascinating to change one bit and affect an outcome of an operation. Just fascinating. I could list many other reasons why but I leave it up to you if you want to step up to be a great programmer and learn how to program in assembly. Start creating a simple Windows app in assembly and then feel the power. You won’t regret it.

Conclusion

I hope that the above points will help those who aspire to become great programmers. Stay fresh; stay crazy because you have the power to change the world!

VisualMASM Source on Github

VisualMASM_1_0-MainI decided to release the source code of VisualMASM on Github. VisualMASM is an IDE for Microsoft Macro Assembler (MASM) and makes it a little easier to create Windows and MS-DOS applications in x86 assembly.

The move to release the source code allows me to share the code base for more feedback and also keep the project going with potential project contributors. The source code that I will be adding to Github is not the current code base but a new version of VisualMASM 2.0. I want to make some big changes to VisualMASM and I figured this is a good way to also share the source code at the same time. You can follow along the changes of VisualMASM as I will build it out more over time and when time permits at the Github repository here.

 

What is a great software design?

I know everyone has their own opinion about what a great software design really is. For me, it’s rather very simple and be summarized in one sentence:

“A great software design can easily be changed in the future.”

In all of my designs, this is my primary goal in any architecture. Be very, very, careful of any library, frameworks, etc. you are thinking about adding. Do not add accidental complexity to your system because it saved you a few lines of code. Do not do it. Keep it simple before you start adding dependencies in your code. You will own this dependency for a long time.

If you are starting a greenfield project, start simple and stay simple until you have no choice and add additional complexity. Resist the temptation of adding this “cool” library or framework.

So, remember, “A great software design can easily be changed in the future.” Stick to your software architecture and stay disciplined and avoid feature-creep in the design. Don’t cut corners and let the team members know that it is important to keep the design simple.

There is enough complexity to deal with because you are creating software. Concentrate on the Ubiquitous Language. Make sure you see that language in your code.

Well, enough rambling, just wanted to write down some thoughts and to remind myself as well.

Creating IDs with CQRS and Event Sourcing in Java and .NET

I’m currently working on a cloud-based system that uses microservices with domain driven design and CQRS and Event Sourcing in Java. I love C# and .NET but I decided to do this in Java for several reasons. This could have been done in C# just as well. In fact, this system is a mix of some C# microservices and Java microservices. The important thing is that we are using the same concepts that are applicable when doing DDD and CQRS and Event Sourcing.

Anyways, I wanted to put down my thoughts on what I have been thinking about since last week and I hope this might be useful to anyone who came across the same question. So, my question since last week was this:

“Who creates an entity id in DDD when doing CQRS and Event Sourcing?”

Well, the way I have been doing this was as follows:

  1. When an application service executes a use case via one of its methods, it can create a new entity via a new immutable value object. All my entities’ ids are immutable value objects.
  2. Sometimes, a factory in the domain model creates new entities. Again, the entities’ ids are created via immutable value objects.
  3. Sometimes, a domain service creates new entities with immutable value objects.

This is all fine and good. I started to look at Greg Young‘s sample C# project at his Github here. For this who do not know him, he is a fantastic speaker and mentor for CQRS and Event Sourcing. Check out his videos, papers, and blog posts. Excellent material. He has a free 6 hour video here. And, while you are at it, check out his video about: “7 Reasons Why DDD Projects Fail“.

What poked my interest was this particular line in his CreateInventoryItem command code:

public class CreateInventoryItem : Command {
    public readonly Guid InventoryItemId;
    public readonly string Name;

    public CreateInventoryItem(Guid inventoryItemId, string name)
    {
        InventoryItemId = inventoryItemId;
        Name = name;
    }
}

If you look closely on line 5, you will see that the entity id inventoryItemId is being passed as part of the CreateInventoryItem command. This is a small but important detail.

I had an interesting thread discussion with Greg Young about this here. Greg raised a few good questions:

  1. What about when you want to send 3 commands?
  2. How will you start returning ids from commands?
  3. What if a command creates 3 entities?
  4. How will the domain get those ids back to the client?
  5. My UI is creating an account then the next step is managing some details. How does the UI go from one step to the next without knowing the account id?

As you can see, there are several good reasons why a client would want to create the ids instead of the domain model. Another reason I would want to add to this is that if the domain would create the ids, it would violate the goal of keeping track of all state changes in domain events with the commands as the initiators. In my opinion:

In a CQRS based system with Event Sourcing, commands carry all attributes that are required to execute the command including the creation of identities.

So, a client can create a command with ids that are based on Guids/Uuids and then send these creation commands with those ids. This allows you to do things such as persisting the commands and being able to replay those commands as well with 100% accuracy because the domain model with arrive every time to a deterministic state when you replay the domain events.

I like this very much and it provides a lot of freedom with inductive UIs / task based UIs.

Modeling Aggregates in DDD

Here are a few notes I wanted to point out when you are trying to model aggregates in domain driven design (DDD). Many times I can’t find the right words or I simply forget what the technical definitions are when you model your domain model or any parts of a domain model such as aggregates. I always go back to the fantastic book “Implementing Domain Driven Design” by Vaughn Vernon. He is a master in showing and explaining it in such a way that I can not do a better job. As I’m currently doing some modeling work over the weekend, here is a summary from how Vaughn is explaining it:

When trying to discover the Aggregates in a Bounded Context, we must understand the model’s true invariants. Only with that knowledge can we determine which objects should be clustered into a given Aggregate.

He talks of how you should design your aggregates. What does an aggregate consist of. So, he goes on with another perfect explanation:

“An invariant is a business rule that must always be consistent.”

Followed by another super explanation:

“Aggregate is synonymous with transactional consistency boundary.”

In the past, I made the mistake of clustering aggregates via composition: “This object A contains object B” which is wrong. Once you understand the bounded context and the aggregate’s true invariants (the business rules), you got it. You hit the jackpot. The light will come on.

Anyways, I wanted to publish this for some time now but never bothered since I always go through Vaughn’s book. But, I thought others might find this useful information especially if you are doing domain driven design and microservices.

Big Data Analysis vs. Big Picture Analysis

I’m sure you have heard the buzzwords around Big Data and Big Data itself. Companies and governments are gathering lots and lots of data about lots of things. Big Data analysis is trying to make sense of this mountain of data and let people make intelligent decisions. It is this Big Data analysis itself I have a problem with. To be more specific, the problem I see is when people are trying to do Big Data analysis without seeing the big picture first. I guess I would call this a “Big Picture Analysis” when you do have all the data at hand but also the reasons “why” you have so much data in the first place.

Let me explain.

Say you have a system or maybe even many computer systems that generate data that you want to analyze at some point in the future.  You may or may not know how you want to analyze all this stuff but you do know that it might come in handy, one day. So, you store a ton of information. By that, I mean the system stores a ton of information into database, log files, etc. Most of the time, you don’t let the system delete anything. You just let the system gather more and more information because storage space is cheap in AWS.

Let’s assume you decided to look inside this mountain of data because you, or the business rather, can take advantage of this data to learn more about your customers and hopefully sell more products and/or services this way.

When you look inside your mountain of data using the latest Big Data analysis tools, you discover certain facts and statistics. You gather, you sum up things, and divide, you formulate, you massage the data, and so on. At some point, you will need to put these analysis results into some form of presentation that can be further used to make decisions. This can be reports, dashboards, etc.

Now, here comes the crux. With all this mountain of data, how can you be certain why you have all this data in the first place? I mean, why did your system(s) store all this data? Obviously, it stored all this data because it was designed to store all this data into databases etc. But, i’m trying to get you to see this from a business point of view. If you have modeled your system based on the domain, then you should be somewhat familiar with the data that was stored in the database. When you have a domain expert look at some of the data, that person might see certain indicators of what this data is about. Or, that person might have no clue even though that person is a business expert, a domain expert.

My point is that when you look at Big Data you should also look at the reasons why this Big Data exists. Only then, you can make a full connection and see the “Big Picture”. When you see the cause for the Big Data to exist, you can make better assumptions and conclusions after you have completed the analysis. You will be able to follow the “thread” from start to end. When you create a report after you have completed your Big Data analysis, you should also see the causes side by side on that report. Only then, you can see the Big Picture.

So, how do you do that? If you are a big fan of domain driven design (DDD), then you are almost there. When you model a domain you also model domain events (most of the time). Domain events reflect a significant event that has happened inside your domain. The past tense is important here. Things have happened already. Domain events capture these events and let you store that these significant domain events have happened. This is when things get very exciting. Imagine what you can do here. Your domain model not only operates on the business domain but also allows you to record of anything interesting that was triggered for business reasons. When you take a look at your recorded domain events at certain dates and times, you can connect your mountain of data and the reasons why this mountain of data was born. The domain events are the reasons why you have so much data. Your reports can reflect and show this connection between domain events and stored data.

At the end, your analysis just received a significant confirmation and validation of having more accurate information. This leads to an even better understanding of the data and ultimately making smarter decisions for those who need this information.