The Purpose of Code

Ask yourself why you write code. If the answer to that question was “to create software”,  you might as well have done it using nothing but zeros and ones, or punchcards for that matter. In fact, creating software by directly modifying bits and bytes will probably result in much faster and optimized software than going through the abstraction of code. Let me illustrate with an example, imagine the following.

class EFRoutingCollectionHasIdCollection : IEFRoutingCollectionHasIdCollection
{
    public bool? GetRoutingCollectionHasIdIfNecessaryClientExists(SomeRidiculouslyLongPocoTypeName entity)
    {
        /* ... I think you get the idea ... */
    }
}

What is wrong with the above code? Let me give you a hint; It’s almost impossible to understand for a human being. Sure, a computer might perfectly understand it, but to a human being, the above code is one notch away from being zeros and ones …

We write code such that other human beings can understand what we are trying to accomplish

That’s it! Arguably the entire explanation of why we’re using code as an abstraction. If you structure your code beautifully, and create reasonable variable names, methods, and class names, 2 years down the road, any seasoned developer can pick up your code, and continue where you left it, without having to spend months simply trying to navigate your class hierarchy, to understand your intentions. In fact, if your compiler also happens to be able to actually create working software out of your code, that’s arguably a *bonus*.

Do me a favour, and look at your code. Is it easily understandable? Can somebody else pick up your code, and start modifying it, without requiring any instructions as to what it does? If the answer to that question is yes, you have achieved something good, and you have created something great. If the answer to that question is no, you should probably refactor your code, and restructure it. Creating great code is hard, very hard, but if you want to create great software, larger than yourself, the benefits of refactoring and restructuring your code “one additional time” always pays off.

Great code is beautiful. You can immediately understand it. In fact, even a person who has never done any software programming himself can also to some extent understand great code. Great code contains as few “clever structures and algorithms as possible”, and can instantly be expanded upon by others. If you are able to somehow write perfect code, comments are arguably superfluous, and the code describes what it does, and spending time teaching somebody else how to maintain your code, is no longer necessary, and your colleagues will hail you, and be happy every time somebody tells them that they are to continue maintaining one of your projects.

Great code is Poetry to the minds of your peers!

Advertisements

Mourning Notre Dame

Yesterday “Our Lady” fell to the ground. A fire destroyed 1,000 years of history, returning her to the dust she once crawled up from. Erasing her from history, as if she had never existed. I don’t care if you’re a Buddhist, Muslim, Christian or Atheist; If you’re anything even closely connected to the way I am, you’re in grief today. Yesterday we lost a symbol of our humanity in a couple of hours of raging fire, and today the world is darker because of it. Regardless of what you feel about Christianity’s history, the Kings who built the Notre Dame, the Conquistadors, the Inquisition, or the priests who abused her during the dark ages – There is no way you cannot see the stunning beauty the Lady herself was, standing there untouched by corruption, as a symbol of transcendence, truly a virgin, reaching for the sky, giving us all hope of something better. A symbol of that we can be better, try harder, and transcend our animal behavior and instincts, and gather around tasks, greater than ourselves. We are all poorer today. For 1,000 years Parisians have pointed at the Lady and told their kids “Your ancestors built that my child.” Today Paris lays on the ground in ashes with a broken back. Today is a sad day …

Ways of Seeing – Software Architecture lessons from my Home

Happy, our happy cat, chasing flies on the wall in our courtyard

To an enlightened software developer, there is little difference between his home and the software he creates. I happen to have one of the most beautiful homes in the Cyprus, and it projects the exact same traits as the software I create do.

First of all, a home needs to have a solid foundation. My home was built 220 years ago, and its walls are 1 meter solid rock. Literally, it feels like I am living inside of a mountain. The same is true for my software. Everything I code, needs to be secure. For instance, when I store passwords in my database, I am using BlowFish hashing, to avoid Rainbow Dictionary attacks to be able to brute force the passwords. If somebody somehow are able to get a hold of my password database, they still won’t get to the actual passwords. This is contrary to the way Facebook stores your password in plain text, implying that if you use the same password at Facebook as you use other places, any employee at Facebook might gain access to everything in your online life. Even though I have access to the database where you store your password, I still doon’t have any idea what your actual password is, and even with a supercomputer, I would still not be able to retrieve your password.

This becomes the equivalent of the size of my walls in my house. In the village where I live, which is Pissouri, just some few hundred meters away from where I live, hundreds of houses are literally sliding into the sea, due to not having a solid foundation, and having been built literally on mud. My home has stood exactly where it stands for 220 years. It’s a testimonial to the brilliance of Nicolas’ ancestors, who built it more than 220 years ago.

Notice how the door captures the light

The height of the ceiling also gives room for great thoughts. Some decades ago, a scientist researched the effect houses had on people’s thought processes, and he came to the conclusion that if you were in a room with lots of room between the floor and the ceiling, you’d be more capable of seeing the “big picture.” Literally, air above your head, will inspire your mind, and give you room to think great ideas.

The “extra yard”

Just like software, your home should go the “extra yard”, to implement details, that sets it apart from the crowd. In our home, there are so many of the details, you feel like you’re walking into a museum as you enter it. Below is from one of our 4 bedrooms, a detail created 220 years ago, probably intended to display saints to protect the home from danger.

One of the 4 large bedrooms the house holds

In addition to this, the living room is divided into two separate places, one for our very large kitchen, and another for the living room. Nicolas did a great job when he renovated the house, to create two distinctly different “rooms”, without walls between them, yet still giving the feeling of that one enters a different room as you go from the kitchen to the living room. Take a look at the next photo to understand what I mean.

Combined living room and kitchen. The photo was taken before we got to decorate it with our furniture

Notice how the “old” merges with the “new” in this single room, divided by the arch, giving a feeling of spirituality and holiness. Just above our sink, is even a hole. It looks like a bird’s nest, but its purpose was to provide a place to but candles 220 years ago, to lighten up things. And just where the red garbage bin is, during the war between UK and Cyprus some 60 years ago, there used to be a food storage room, where Nicolas’ family used to hide soldiers fighting for Cyprus independence.

If you’re a software developer, you should treat your home as your software, and your software as your home. Because they both reflect truths about you, and how you think. And in the end, the creation of software is not the creation of code, it is the act of thinking. And to think beautiful thoughts, you need a beautiful home. A man’s home is his castle, and his castle reflects his mind. If you have a dirty or messy home, this will reflect on your work, regardless of what your work is. Below are some more pictures to hopefully inspire you to “think better.”

The hallway between the bedrooms and the living room. You have to bend your head as you walk between the living room and the bathroom/bedrooms. I think this is a reminder of being humble as you walk through the cathedral your software, and your home, really should be treated as

Notice the arch, and the vine rank, that’s been turned into a light. You can also see the old “light hole” on the wall behind the vine rank

Ways of Seeing, is that which separates the apes from humans …

And of course: Location, location, location! This is what we see if we leave our home. Less than 50 meters from our home, the most beautiful village in the world; Pissouri!

What is Dependency Injection

Dependency Injection is often being used when you want to decouple your components from each other, such that exchanging implementation later becomes easy. It is based upon interfaces, combined with an “instantiation trick”, that allows you to declare anywhere you wish what implementation class to use whenever somebody for some reasons needs a class implementing some interface. The Ninject website easily explains this using the idea of a Samurai that needs an IWeapon, implying that the Samurai can use any type of weapon, and that he doesn’t care about what weapon he is given.

If you look at my Magic for instance, you will notice that I exclusively pass in my services as interfaces, to my controllers. Then I bind my interfaces to some implementation class using Ninject. This allows me to exchange my business logic, if I need to do that later, without modifying my original service class. For instance, I might later need to cache parts of my database access, at which point I can simply create an ITodoCacheService, implement ITodoService on it, and make sure I bind ITodoService towards ITodoCacheService. This avoids forcing me to change the logic of my original ITodoService, yet still use my new cached ITodoService where ever I need caching.

Then when ever I need an implementation of ITodoService, I don’t create it directly, but rather request it from Ninject, through something such as “Kernel.Get()”, instead of creating my instance directly, which makes sure I get the correct implementation class every time, according to my bindings.

Dependency Injection is crucial for any large scale real world app, due to its ability to decouple your implementations, resulting in higher amount of “encapsulation”. This blog was written as a consequence of somebody asking me the question in the header, and I realised that few junior developers actually understands this crucial concept – Hence, I wanted to write up something about it, in an attempt at trying to teach something important, to those needing to understanding the concept.

The difference between a Junior and Senior developer

Having created code for 36 years, since I was 8 years of age in fact, I have seen many junior developers and many senior developers, obviously – And I can tell the difference within the blink of an eye. Show me your code, and I will tell you how good you are. Which is always why the first question I ask as I interview developers is “Do you have a GitHub account?”

Others will focus on giving away tasks, while I will ask a developer if he can show me some code he has done. I don’t care if you can’t implement Quick Sort, in fact, to be honest with you, I don’t think I could have implemented Quick Sort myself without looking it up. If I ask you if you can implement Quick Sort, the only thing I’ll have an answer to, is how good you are at preparing for a job interview. I still won’t have any clue as to how well you’ll perform in an actual job setting. If you show me your code though, I’ll have an answer to how good you are within some few minutes, and I will know if I can give you architectural responsibilities, or if I’ll have to hold your hand for years.

The reasons for this, is because your code shows me what choices you will do when confronted with a problem. Will you use Entity Framework or NHibernate? Will you use Mapster or AutoMapper? Do you know how to use Dependency Injection? What about Modularity? Can you create a modular solution, without dependencies between your different components? Only your code will show me the answer to these questions …

To bridge the gap between seniors and juniors, I have created a micro framework called Magic. It’s probably less than 1,000 lines of code, and can easily be understood within an afternoon, even by the junior developer. In many ways, it’s the Magic pill that will turn a Junior into a Senior, because it creates the structure for your projects, that a really great senior developer would always start out with, and does the right choices for you, in regards to which tools to use. The framework is based upon 36 years of experience with coding, and implements the design patterns necessary, to create a great structure, for any new project using ASP.NET Core, HTTP REST and C#.

It’s a Magic pill that will make you a Senior Developer in a couple of days

Simply because as you study it, and start understanding it, you’ll also make the right choices in the future, and avoid having to spend 36 years teaching you why you have to do things the way I do them …

Download the Magic Senior Developer pill!

Turn a Junior Developer into a Senior Architect for €50

Arguably the largest practical difference between Martin Fowler and John Doe junior developer straight out of college, is that Martin Fowler is able to create an architectural foundation that is much more scalable and resilient towards change, and can more easily be explained – Resulting in that your software project has a higher success ratio with Martin Fowler at the rudder, than it would have with John Doe at the controls. Hence, if we could somehow magically make sure John Doe Junior is able to create that same brilliant architecture as Martin Fowler, we could reduce the salary costs by 80% of our software projects, without reducing the likelihood of success.

Meet Magic

Magic does just that. It’s basically a framework that allows any junior C# developer to create his or her next web API with the same beautiful architecture as the best software architects in the world would choose. It’s based upon 36 years of experience as a software developer and architect, and created by one of the most read article writers at MSDN Magazine writing about C# design patterns and architecture. It’s the culmination of all best practices your software shop needs to be able to magically pull the rabbit out of the hat, again and again and again. And it doesn’t cost you a million dollars per year like Martin Fowler probably would. Nope, its cost is €50.

In such a way, starting out with Magic, creates an insurance for you and your little dev shop, and increases your likelihood of success, such that instead of having a 75% chance of failure (true numbers) in your next software project, you could significantly reduce that number to have a higher chance of success.

In addition, it’s Open Source, allowing you and your best developers to scrutinise its code before you purchase a commercial license. But don’t believe my words. Send it to your best developers, and ask them about their opinions. Then come back and buy a license as they give you their verdict. If you require additional support, I am for hire, and I also sell access to private training YouTube videos about Software Architecture. In addition to that I teach Software Architecture and coach juniors. Feel free to contact me below is this is of interest.

Hiring Jon Skeet for €50 per project

Reproducing brilliancy with a Xerox copier!

If you want to hire somebody like Jon Skeet to architect your next software project, you’re going to have to have really, really deep pockets. Chances are he won’t even answer your phone, before you’ve offered him €500.000 annually. The same is true for any of the top C# architects in the world, such as Martin Fowler, Ayende Rahien, etc, etc, etc. Unless your name is Google, Facebook or Apple, and you’re willing to dig up half a fortune, these people will highly likely not even bother answering your emails. This problem results in that the statistical probability of that your next software project will turn into a big ball of mud becomes roughly 100%.

I got tired of this problem, and I realised I could solve it, by creating a skeleton architectural “starter kit” for your next software project, that out of the box, applies all of the best practices that these people would normally charge you (a lot) to help you out with. For the record, neither Jon Skeet, Martin Fowler, Ayende Rahien or anybody else from this camp has been involved in Magic – Still Magic applies these architects’ best advice, simply because these people have presents on blogs, StackOverflow, etc. And there they have been giving away their best advice for years, free of charge, to anybody willing to spend 3 decades reading their stuff, and extract all the best parts.

Meet Martin Fowler, the good parts

For instance, the unit tests in Magic, applies an advice originally coined by Ayende Rahien. Of course, Ayende’s blog about SQLite Unit Tests for nHibernate is a decade old, so his code no longer works unfortunately – But I used Ayende’s ideas, updated it to 2019, and applied them into a general framework for Unit Testing nHibernate database controllers. In addition, Magic applies a very good foundation for Domain Driven Design, that Martin Fowler have written several good books about. And a lot of the inspiration behind Magic comes from ideas shared by the general community at StackOverflow.Com – Where arguably most of the best answers are written by Jon Skeet. Below is an example of what you can do with Magic in some few seconds …

So hold on to your hat, and download Magic today, it’s only €50 for a commercial license anyway, because …

… you simply can’t afford hiring Jon Skeet, unless you’re Google. But you can probably afford €50 for all of his best advice, distilled into a tiny architectural framework, such that even your Junior developers will simply “automagically” create Jon Skeet quality code and architecture, straight out of the box!

A Software Factory Process Proposition

There is nothing magical about the creation of software that doesn’t allow us to automate it. In fact, arguably the sole purpose of software, is automation of processes – So why haven’t we been able to automate our own processes? Why haven’t we automated the creation of software itself?

When Henry Ford started producing cars, he would look for places where he could standardise the construction process. This obsession went so far that he jokingly said “You can get a Ford car in any colour you wish; Black or black.” The idea of course, was that the colour black would dry in half the time other colours needed to dry, and that by standardising his colours, he could simplify the process of construction, resulting in that he could produce more cars in the same amount of time, resulting in less expensive cars for his consumers, and higher market shares for his company. As a consequence, an entire colour industry spun of in his trail, creating hundreds of additional companies, who’s sole purpose was to repaint cars to whatever colour the customer actually wanted after they had purchased a Ford. These companies for obvious reasons had an incentive to make sure Ford would gain even higher market shares, and hence such ended up advocated the advantages of purchasing a Ford. By underdelivering, he gained even more milage on his competitors.

If you look at the software creation process, most of our work is repetetive in nature. This is a sign of that our workload in these regards lends itself to automation. Everything that is repetetive in nature, easily lends itself to automation. Hence, arguably 80% of our processes can be automated. Few employees today are more expensive than software developers. If we can automate 80% of a software developer’s workload, we can cut the cost of creating software down by 80%. Hence, by automating our own jobs, an application that would normally cost €100.000, would end up costing €20.000 instead, and we have facilitated for a “software factory” – An assembly line production facility, that allows us to create software faster, less expensive, to more people, than our competitors can do. Needless to say, but such a facility would arguably within months of starting up, literally acquire monopoly on the process of creating software.

What colours do you want for your web API? You can choose; Black or black

Check out Super DRY Magic here

Software development simplicity

The by far greatest challenge when creating an application, is how to reduce complexity. This is especially true for web apps, since they by the very definition require you to use much more “moving parts”, such as JavaScript, CSS, HTML – In addition to some server-side programming language. Entire libraries have been written about the importance of simplicity in software design, yet these are basically from a practical point of view useless when creating web apps. Simple questions such as “how to I store my passwords for my users” can easily require weeks, if not months of development. Resulting in that before you can even start looking at your domain problem, you’ve spent a year trying to solve “commodity problems”.

Phosphorus Five attempts to solve these problems for you, such that you can start out creating YOUR app from the first second of coding. For instance, how to create a modal window is answered with a handful of lines of code in Phosphorus Five.

micro.widgets.modal
  widgets
    h3
      innerValue:Header of modal window
    // Whatever HTML widgets you want to include additionally

Ask yourself the following question for instance; “How can I (securely) invoke code on my server in an Ajax request, as the user is clicking a button, and how do I create that button?” – Well, that’s 5 lines of code in Phosphorus Five my good friend …

create-widget
  element:button
  innerValue:Click me!
  onclick
    // Do something on your server here ...

It doesn’t take a rocket scientist to understand the advantages of the above compared to hand rolling your own XHR Ajax requests, using JSON to return data from the server, implementing a method in for instance C# that evaluates a piece of code on the server-side, etc, etc, etc. The equivalent jQuery/C#/JavaScript solution for the above piece of code, would easily become 50-100 lines of code, in at least two different programming languages.

Let’s start out with the most difficult task from the beginning of this article, which was as follows; “How do I securely store my users’ passwords?” – Well, in Phosphorus Five that’s ZERO lines of code! Because it’s simply there! Phosphorus Five has a pre-built authentication/authorisation module, allowing you to easily create, edit, and delete users in your system, with some 3-5 lines of code. Below is an example.

p5.auth.users.create:some-username
  password:some-password
  role:some-role

And when the above event has done its job, you have a new user, securely stored in Phosphorus Five’s encrypted users file. This file is encrypted with a PGP key pair, that’s securely stored in GnuPG format, outside of the file system available for your web app. And even if an adversary were to somehow magically be able to decrypt it, which should be impossible might I add – The passwords for your users are still stored as server-side salted hashed values. And the (default) password regime in Phosphorus Five denies a user to create a password that can easily be brute forced attacked with a Rainbow/Dictionary attack, since it requires the password to be at least 25 characters long, hence resulting in that an adversary will need a computer the size of our galaxy to perform a Dictionary attack on it.

If the above paragraph didn’t make any sense for you, relax my friend. The average website’s security is arguably at the point where a teenager with some script kiddy’s skills can literally access your “everything”. With Phosphorus Five, even the CIA or the NSA would highly likely not be able to access *ANYTHING* from your web apps’ sensitive data. Hence, you don’t need to spend months learning how to securely hash your passwords, or securely encrypt your password file, or securely prevent access to your passwords from the application level, which easily might slip for you if you allow for a simple SQL injection attack at any level of your application. With Phosphorus Five you start out with 95% of your job already DONE!

Creating web apps is about reducing complexity. Phosphorus Five is *DEAD FREAKIN’ SIMPLE*!!

And it’s free 🙂

Download Phosphorus Five here

Software Architecture lessons from Norwegian Soccer History

Everybody who knows anything about Norwegian soccer history knows we’re like the worst soccer players on the planet individually, maybe the only ones worse are the Swedes and the Danish … 😉

Individually, it’s like we are physiologically incapable of playing the game. If you compare the average Norwegian soccer player to a Brazilian soccer player, it feels like you’re watching a Giraffe play tennis as you’re watching the Norwegian guy trying to “samba” his way through the field …

However, 25 years ago, there was this magical soccer trainer. His name was Egil “Drillo” Olsen (Google him). He broke all known soccer theory at the time, such as instead of having his players exercise on parts they were bad at, he had them exercise what they were already the best at. For instance, there was this one guy, who’s sole purpose was to shoot the ball, from one place on the field, to another place on the field. He was very good at shooting accurately and hard, but had no other skills really. Another guy’s job was to simply stay at that spot, pick down the ball from the air (his specialty), and score a goal. All other players were chosen from similar criteria, and none of these were “the best” in soccer in general. Individually, the team was arguably composed out of a bunch of “soccer retards”. However, this team humiliated many famous soccer teams, such as Brazil, Germany, England, “you name it”.

So let’s move this theory into software teams, and see if we can learn something. Let’s imagine we’re going to create a web application. OK, we know we’ll need JavaScript knowledge, so we find the best JavaScript developer in the world. We know we’ll need HTML and CSS, so we find the best CSS guy in the world. We know we’ll need C#, so we find the best C# developer in the world. However, these guys’ individual skills, become a liability to create our application. Simply because our app as a whole, doesn’t care about the brilliance of its C#, JavaScript or CSS code. Since all of these guys also are so darn special, and the most skilled in their area of expertise, they’re often also filled with vanity, and an incapacity to cut corners, in order to make their results *integrate* with the results of the guy sitting next to them. And they’ll often hold hourly long speeches about why they can’t do what they’re told to do, because of a, b or c. In fact, this problem is so common, it’s referred to as “Mythical Man Month”. If you haven’t heard of Mythical Man Month, I’ve included it below. Realise that this “theory” of software development is arguably proven scientifically, several times. It goes like this …

One man can create in on month, what two men can create in two months

Although we have known about Mythical Man Month for almost half a century, I suspect we don’t really know the reasons for it. At the least, we do NOT know how to fix it. However, I suspect Erik “Drillo” Olsen might actually have the solution for us.

The quality of your individual employee’s job is actually completely irrelevant. The only question you should be asking yourself is; “How can I integrate his results with the results of the guy sitting next to him”. This is such a universal truth, I suspect that you could literally handpick a bunch of medium skilled software developers, with the sole aim of asking how you can integrate their combined efforts, and these “mediocre” developers would far outperform a team of the same size, composed of the “best guys on the planet”. Kind of like Norway humiliated Brazil in soccer some 20 years ago …

So let’s move this on to *framework design*, which my previous article was all about. Well, the same laws applies. If you want to create a web app, you’ll need to pick a JavaScript library, so you pick the best. You’ll need to pick a CSS framework, so you pick the best. You’ll need to pick a database, so you pick the best. You’ll need to pick a server side programming language, so you pick the best. Etc, etc, etc …

AND YOU NEVER FINISH YOUR PROJECT!!!!

Because the quality of your individual parts, is completely irrelevant, because you can’t integrate these into a “whole”, because they’re built with different philosophies, architectural design patterns, goals, etc, etc, etc. And the vanity and belief in that every single library is created “perfect”, makes its maintainers incapable of perceiving anything wrong with their tools. From their point if view, it’s already *perfect*!

I suspect this is the root of all failed software projects in fact. At least intuitively it feels like a universal truth. If you instead focus on integration from DAY 1, and cut a couple of corners if necessary on quality and performance on your individual components, the end result becomes far superior, and much more easily maintained. Simply because your different individual parts doesn’t scatter “all over the place”, and focus on their individual success. They are rather focusing on the group’s success as a whole. Hence, your framework, realises it is not existing as a bunch of single entities, but rather as a collection of entities, such that group dynamics kicks in, and decides the faith for it as a whole, and hence your ability to deliver good quality end results to your clients at deadline. So hence, an inferior software development framework measured on its individual parts’ performance, will still run in circles around the combined efforts of the “best individual parts in the world”.

In fact, this also consistently improves security too, even to the point where you’ll have to cut corners, arguably from an individual point of view reducing security. The last Efail security concern about encrypted emails for instance, was not a problem with encryption standards, it was not a problem with email clients. It was in fact a problem where you could not put the blame on any single individual component in your system. Still the security flaw was as real as daylight. I happen to have this knowledge from “the best MIME library creation expert on the planet”. This was a bug in how the encryption libraries were *integrated* into the email client! So arguably, even to the point where you’ll have to “cut corner in regards to security”, security as a whole still improves, simply by realising it’s not about the individual component’s performance. It’s about “the group” as a whole (framework), and its ability to perform its task as a whole!

Mythical Man Month … What month did you say …?