While watching the video below, I was intrigued, when this interview questions was discussed (timestamp 56:30-57:35).
It made me think about my response, had I ever been asked the same. And it did not take too long before the answer was clear: the B-Tree. There is a very good section on it in Martin Kleppmann‘s book “Designing Data-Intensive Applications“. And I highly recommend this book anyway.
But as a starting point on B-Trees the following video is also quite helpful:
A bit different form what I usually post, but a fascinating topic.
I just came across another interesting statement about the size of development teams:
What makes this so interesting is its origin. It was said in 1968 during the famous NATO Conference on Software Engineering. Fifty years later I think this is still remarkably true. But why?
In my post on the size of development teams I was aiming at complexity and scope as drivers. The interesting question, though, is whether there are additional points to consider. Having worked pretty closely with some other projects in the meantime, I came across another influencing factor: availability of qualified staff.
You can look at this in several ways. The first hurdle is obviously to have enough developers with the required experience at your disposal. The second is how to allocate their capacity to the portfolio of activities you run. Or put differently: How do you deal with the shortage of know-how you face? Because, let’s be honest, there is always more demand for highly skilled developers than can be supplied. (I am having a déjà vu with my “beloved” macro economics lecture 😉 back in 1996.)
If your organization is above a certain size, chances are that overall a sufficient numbers of good people work there. Does that put you in a better position than some poor fellow working for a small company? Not really. Because your project competes for these folks with all the other work within the organization. And what is the difference compared to competition with an external market? Yes, if you have really goof connections to higher management, you can escalate things and possibly get additional people. But you will also burn bridges in the process, which is usually too high a price.
So instead you probably end up with the usual mix of folks: Very few rock stars, many middle-of-the-road folks, some promising newbies, and the occasional looser that nobody wants. Can you deliver something really great with such a mix? It will be difficult in a typical corporate setup where you have to somehow involve everybody. And this involvement of the less qualified half of people will slow down the “upper” half.
It is a very delicate subject and there are many fine lines, some from a legal perspective and many more from decency-to-others point of view. Also, the organization needs to think about tomorrow and therefore must have a “funnel” of to-be-rockstars, which need the best training they can get. And the latter is always working on a difficult project with experts and learn from them. But what few organizations do, is look at competence levels in detail and factor them in.
In other words: You can learn a lot from someone who is one, two, or perhaps three levels above you. But if someone is ten years ahead of what you currently know, the difference is just too big. You will only grasp a small fraction of what they teach you, and even that with a considerable risk of misunderstandings. And they honestly cannot understand why you are not following their great advice. Mutual frustration and dislike are usually the result.
Whether you take competence levels into account or not, considerable effort needs to be spent on non-development activities. If you have a taste for management and leading people that will be a great opportunity for you. But if your primary concern is getting something great and possibly visionary delivered, you should seriously consider a totally different approach: an underground project.
Flying under the radar can really be liberating. This must not be confused with idling around or working on some obscure pet project. It is truly about delivering what the organization needs but cannot accommodate in its own structure. Of course you should be certain that your boss will not fire you, if he or she finds out. But as you probably already guessed, driving an underground project does not mean that you are freed from politics, lobbying etc. On the contrary! You must prepare upfront quite carefully how you counter resistance or outright attacks. And yes, you are running a personal risk. But there is no reward without risk.
I cannot say how often I read in some company’s image brochure that management and expert career paths are treated equal. There must be companies on our planet where this is true, but I have yet to see it in practice. Why is that? (Unless mentioned otherwise this article is about the IT industry with a strong focus on consulting and software companies.)
In my experience the core reason is a fundamental lack of understanding from the non-technical folks that make the relevant decisions, i.e. management. They have a vague impression of techies that is often dominated by perceived social deficiencies (“They can’t look me in the eye”). While the latter is sometimes true, how can it be a measure of someone’s qualification to perform a complex technical task? And perhaps there is actually a good reason for averting my eyes. I cannot speak for others, but when I have a complicated discussion, it helps me focus all my mental capacity on the problem at hand when I look onto the table.
I would speculate that, as in so may other cases, the heart of the problem lies with mid-level management (where the details are determined) as opposed to the C-level. Taking into account the Peter principle, what does that say about middle management? Yes, this a strong simplification and it does many people injustice. I have personally met quite a few people on this level that I consider great at their job, particularly including leadership skills. But just as well did I encounter folks who cannot think out-of-the-box and blindly follow rules and processes. And it is this capability to see new ways, make realistic projections about what will (not) work, and lead by example “where no-one has gone before”.
A particularly interesting story for me was the encounter with an HR person where we talked about setting up an initiative to advance technical folks (what is often called a high-potential program). My idea was met with friendly resistance and the argument was made that contrary to management, the technical side is so much more diverse that it would be virtually impossible to have a single program. In fact this HR person seriously thought that every techie needed his or her completely individual program.
My counter argument then was that this would not be a technical program (learn programming language XYZ) but one for professional and personal development. So we talk about e.g. how to present a complex technical scenario to upper management for getting a budget approval. Or how to engage with a customer and instill confidence that a given product is the right choice to solve their business problem. And all this with being authentic and building upon the strong technical knowledge one has.
I don’t want to appear as simply bashing HR here. But the underlying problem was that assumptions had been made about what would be suitable for technical folks without ever having spoken with any of them. Would this happen the same way for management staff?
From a more abstract perspective it comes down to the fact that many decisions are made based on personal trust and relationships, rather than on processes and policies. So what is needed is that the relevant management and technical staff (on every hierarchical level) talk to each other in the spirit of equality. And here both sides fail miserably too often.
Pi-hole is a great and easy addition to security. The automated installation is a nice thing, but did not work on my system. The core of the problem was that I wanted to install it on a Rasperry Pi that already had dnsmasq running on it. And of course that dnsmasq was configured to provide DNS services to the Pi. What then happened was that, as an early step of the installation, the dnsmasq daemon was stopped. Logically, the Pi-hole download that was supposed to to take place, did not work.
After a few tests the following approach showed to work
sudo systemctl stop dnsmasq.service
/etc/resolv.confto point to the DNS server in my router or something like 18.104.22.168 (dnsmasq sets it to 127.0.0.1 on every start or stop)
We are used to terminal sessions displayed like any other content, i.e. as a video of some kind. The latter comes with two caveats, though. It uses a lot of bandwidth (compared to the actual terminal session) and is often difficult to read. Because many people do not bother to magnify the terminal either during the actual presentation or as part of the post-processing.
In addition to using the hosted instance, that supports sharing in multiple ways, you can also run your own server via Docker. For all the details, please go to the website.
When the schedule is tight for a software development project, one of the first things non-technical people contemplate, is reducing quality and/or scope and go for an 80% solution. This can work but only under particular circumstances.
A recent discussion I had with some folks was about such a situation. A very tight deadline had been issued by senior management and multiple departments had to collaborate on a solution that spawned multiple parts of the organizations and their core IT systems. Those systems (think about something like ERP and CRM) have a multitude of connections, grown over many years without governance, but not for the data that were required now.
The people were all quite supportive and a constructive discussion took off. Not surprisingly, finding a common language took some time. Especially so because only after a while did we realize that in several cases the same term had a different meaning. In the end there was a particular detail where no obvious solution was available.
I was responsible for the technical implementation on one of the two systems involved. My counterpart on the business side and I discussed various options and and eventually he came up with the idea to just safe time by going for the 80% solution. We talked about a number of aspects and it soon became clear to me that this would actually require more time than to just “do it properly”.
This sounds, at the very least, counter-intuitive for most people. So let me illustrate my point with a non-technical equivalent. Many years ago I had to prepare for my then-boss a list with press clippings every day. It basically meant to go through a long list, that was created automatically, and remove everything he was not interested in. This was quite time-consuming and he was genuinely surprised when he found out.
His statement then was “Why do you need so much time, it is only 20 of the 200 articles that are relevant”. That was of course correct. But what he had not thought about was that I had to go through the list of all 200 articles and check some in more detail than just looking at the headline. So it did not really make a difference whether I cut the list down to 100 or 60 or 20 articles, the time required stayed more or less the same. He agreed on the point and quite soon decided there was better use for my time.
It is exactly the same with taking shortcuts during a technical implementation. The easy part is to decide that you want to cut 20% off the next release. But things get tricky when it comes to deciding which 20% to skip without any undesired side-effects. In order to be able to do that, you need to understand in depth what the consequences would be. So quite often you spend more time trying to understand potential ramifications for various scenarios, than it would take to simply do it properly right from the start.
And that is only the beginning of the problem. You need to document the results of your analysis really carefully, if you want to be sure that nothing is missed when the first code change is required. Even a seemingly minor bug fix has an increased potential to break something if the current overall solution is built on a set of assumptions. And adding enhancements or new features will be even more “fun”. Because people have to read through all the documentation and also understand it. Together this is a time-consuming task with considerable risk to still overlook something (or hit an edge-case that was not documented).
But in reality this documentation does not exist anyway because you wanted to save time in the first place. And detailed documentation is not exactly supportive here. So people throw in bits and pieces and you end up with a document that is typically even worse than most project documentation that is out there. So whoever has the pleasure to work on the code without having all the details in mind is really screwed. That includes you, by the way, because you will have forgotten most after only a few weeks.
The solution is usually a re-implementation because it is faster than to fix the broken code. Of course that re-implementation often needs additional logic to handle data migration for transactions that were completed with the 80% solution and now ruin your data quality. But hang on, that might just be 20% effort you can safe right now ….