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 …
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.
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.
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.
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.”
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!
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.
I’ve just created a 10 minute long video that allows a recruiter, without any software development experience, to recognise and see the difference between the code of a junior developer and a very, very good senior developer. I’ll wrap up a check list, and probably create some sort of statical analysis toolkit later for you guys, but at least for now, here’s a good beginning.
I am also for hire to look through code, and analyse it for flaws, if some recruiters wants my services. But this will (obviously) cost you. But it’s an inexpensive insurance towards making the wrong choice, and ending up hiring the wrong guy, believing in the bullshit he says about his own code.
Hiring a developer without seeing his code first, is like hiring a musician without having heard his music
Contact me below if you’re interested in having me analyse code for you.
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 …
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.
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.
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!
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 …
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 ...
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 🙂
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”.
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 …
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 …?