Why your software shop is failing you

I have been in the software game for 25 years and it shocks me how many of the shops I have worked in were, to varying degrees, ineffectual. There are, of course, the obvious reasons that this could be the case, such as bad developers, a bad company culture, cash shortfall, whatever; but I want to focus on the strategies that are purposefully put into place that cause failed projects and wasted time.

One of the biggest hurdles I see in new projects, especially lately, with all the libraries, frameworks, and development ideologies coming out is the “cart before the horse” development house. You get hired and put on a team run by some fancy ex-Big Tech director who wants all the bells and whistles on this project. He wants to start the project with string translation files for all the major languages. This has to be updated for every checkin. Also, for scaling purposes, the backend API needs to be broken up into microservices so that each service can be deployed and worked on separately, as well as scaled independently. Also, lets have strong linting and a fascist developer approval process for checkins that block any push where the code block doesn’t start until after the “if” statement, and there is a space at the beginning and end of every parenthesis. Also, this guy read “Clean Code” so all the code has to be convoluted, obtuse, and impossible to update; or well, you’re just a dumb developer. Shoehorned Strategy pattern and unnecessary Dependency Injection for the win. Oh, lets not forget we have to set this thing up with horizontal scaling on a Kubernetes Cluster in multiple regions right out of the gate. 100% testing coverage anyone? How many customers do we have? Oh, zero… well maybe we should worry about some of this stuff when it actually becomes an issue, and not when our company is paying a million dollars a year on a development team that is writing a piece of software that is yet to see the light of day, where every feature development cycle is hamstrung because of all the baggage loaded onto it.

It shocks me when I am hired onto a team of A-team developers, who have 50 plus years of software experience, and Computer Science degrees between them to have all of our decisions made by a project manager or scrum-master with no programming experience, a liberal arts degree, and a weekend Agile Scrum course as their full list of credentials. Oh, we should use React.js to write a full fledged web app that would be better suited as a monolith in Rails? Oh, you read an article. OK, I will begin downloading the 200 libraries I need to make React pretend to be a web solution and make sure to bill you hourly. If your project manager is removing roadblocks and coordinating with other teams, kudos. If they are running our shop, wrong answer. Why did I have to do a sample project, take a Leetcode test, a drug test, and give you a blood sample, before I even got an interview, if I was just going to be told what to do by a glorified toddler. You hired smart developers. You pay us a lot. Let us do our job and stop sabotaging us.

The last item I want to mention is closely related to the others. This is using technology because its popular. I am a javascript front-end developer. I do this professionally. When I am writing my own projects, I almost never reach for front-end javascript stacks. These should be used as seasoning on top of a full fledged app, and not as the backbone, pun intended, of your flagship solution. It seems like 95% of companies are using solutions that 5% actually need. Add on to this Redux, Typescript, and a million other libraries, and then you wonder why it takes 200 lines of code and 18 files changes to add a checkbox to a form. You don’t need microservices on Kubernetes, or React, or a super fast compiled language API with separate teams to support them all. You don’t have any customers! I can write you a nice Rails or .NET app in a few weeks that will suit your needs. Its mature, its stable, and it works.

And furthermore… Agile. Lets have 20 meetings a day. Maybe some useless administrative theatrics a la Jira with 15 plugins. Hey lets pull out the playing cards, bouncy ball, and a peace pipe so we can estimate the “complexity points” of this feature. I am not a moron, I can give you a time estimate. You wouldn’t need to measure our “momentum” if you would stop wasting half of our arbitrarily timed “sprint”, and let us get our work done. It really is sad, because this is not what Bob Martin had in mind when he and his friends wrote the Agile Manifesto. Corporate Agile is an unholy abomination, hijacked by the previously mentioned pointless middlemen, to destroy developer productivity, and it should be put down like a rabid dog. We can keep the kanban board if this makes you sad.

I don’t want to sound like a Negative Nelly here, but during this time of mass tech layoffs, it seems like companies would want lean, efficient teams, not pointless bloat and wasted development cycles. But things seem to be getting worse. This doesn’t have to be the case. Developers are trained to write software. We really can do it. We know our toolset. Just trust us.