Author: nsledgianowski

Looking from the inside out.

I started my software engineering career in consulting. We did application development for large companies that did not have enough engineers on staff to get their projects done. We had a Statement of Work and a list of stories to do. Then we handed over the code and went back to our nice benches. Consulting was a big thing, we had executives, million dollar contracts, etc. I often ran in situations where I was spinning my wheels waiting for people to make decisions or to sell another contract. We ran some internal projects, but they were always an after thought. 

Now I work in a product company somewhat similar to the companies we used to consult with. We have what is essentially an unlimited amount of work. There isn’t any time for anyone to be ‘on the bench’. We have enough work for double our headcount. I have 5 real, valuable projects that I want to work on. It is just an issue of prioritizing and getting things done. But the thing is, a lot of stuff is falling through the cracks. 

We don’t have time to do everything, but we do need a lot of things improved. 

We could use an expert on CI/CD pipelines to come in for a month and upgrade our pipeline. We could use a java performance expert to come in and help us cut end user latency by 50%. We could use a consultant to help us break up the monolith. We have opportunities for a dozen consultants, but from the outside you don’t see the internal workings of the product company. You can’t see that we have hundreds of ways to make the product better and no where near enough work to do it. 

Solutions Pyramid

In College Computer Science Majors worry a lot about the optimal solution to algorithmic problems. What is the optimal solution? Is it in logarithmic or polynomial time? Did you pass or fail the test? My Algorithms class had a group class competition to see which team could find the best solution to a particular algorithmic problem. 

Then when they start looking for jobs they run into whiteboarding interviews where they are supposed to find the optimal solution in 50 minutes so we have time for questions. 

But once you enter the workforce, no one cares about the optimal solution anymore. If you look at the Solutions pyramid above there only one optimal solution. But right underneath there are 10 excellent solutions and a 100 good solutions. In the corporate world a good solution is an A grade, and an acceptable solution is passing. Typically as long as a enterprise software project avoids clearly ‘bad’ algorithms it will probably meet its throughput and latency goals. 

When your team has found multiple approaches to solving a problem and can’t seem to agree on the ‘right’ one. Ask yourself whether any of the solutions are in a higher level of the pyramid than the others. Don’t try to find the best solution, try to get a solution from the highest level of the pyramid implemented. And if all the proposed solutions are from the same level of the pyramid, sit back and relax, it doesn’t matter who wins.

You should not “build it here” even if your core competency IS Software.

Some companies try to avoid developing software that doesn’t directly contribute to making money. Other companies do the opposite and try to only use internal software. Falling into the “not invented here” trap.

Large software companies fall into a different failure case where they build large massively integrated internal development platforms. 

At the beginning these companies were solving a problem that had no existing solution and they correctly chose to create internal solutions. 

But it has been a long time. You should not be maintaining your own containerization system anymore. Use Docker. 

But for a big tech company moving to docker could be a five year effort costing millions. It is easier to keep the old system.

That large tech company gradually becomes trapped by internal software, that the rest of the industry has never heard of. As the company’s internal tech stack drifts away from the rest of the industry employees pay less attention to the mainstream.

Eventually the company loses perspective on what they are missing. The people who have worked there the longest who have the most power to improve things think the internal software is better. 

These companies are big enough that they have internal developer conference where employees can learn about the latest in internal tooling. 

Today most of the components of these stacks are worse than the industry mainstream alternative. But there is no upgrade path on the horizon.

Bookshelf Post

I have gotten back into reading Software Engineering books. It has been a good change of pace to study a bit in the mornings. My current focus is on Estimation. I want to come up with a better more accurate way for us to estimate software projects in agile environments. 

These two books are great references. Designing Data-Intensive Applications is a good read and believe it or not my workplace still uses Java 8 so Java Performance is not out of date.

I got these two management books back when I was a manager for a few months. But I haven’t dug into them yet. 

Agile Software Development was a textbook back in University. It is a funny book since it has about as much space devoted to Agile as it does to Object Oriented programming. The Mythical Man-Month is fun because of all the references to technology in the old days before the modern web. 

Building Products for the Enterprise is a product book, but I really like how it really explains what those Product Owners are up to all day.