3 ms·

> Large codebases are inevitable. I vehemently disagree. New codebases might be built on top of large stacks of framework code and infrastructure code, but sou

> Large codebases are inevitable. I vehemently disagree. New codebases might be built on top of large stacks of framework code and infrastructure code, but source repositories ought to actually be tighter and more business-focused than they used to be. But they're often bloated monstrosities, filled with resume-padding architecture astronaut bullshit, or contorted to fit the latest hip framework's requirements. Apologies ahead for this long-winded rant, but this exact issue has been boiling my blood for weeks now because I've been wading through the neck-deep mess that a customer has made, such as writing an astonishing three megabytes of source (typed by hand, not generated!) for a single web form. One! Especially in the era of modern web frameworks, we can avoid most of the "ceremony" of older systems like C or C++ where just making a call to a database was pages of fiddly boilerplate. Instead of embracing this, I see developers reintroducing unnecessary code because they must have gotten so used to the verbosity that they felt exposed without it. Let me give a concrete example from a codebase I've just spent a week reviewing. I've read through hundreds of pages of code, found dozens of critical resource leaks and security issues, and I'm yet to encounter any actual business logic. The first mistake that happened was that someone decided to use Angular. Why? It's hip! It's cool! It's what all the kids are doing! Except now, you have to have an API instead of just web pages. That API will need to serialize things to JSON, so you need to data transfer objects and Newtonsoft code. Suddenly, you need to deal with JWT, and make sure the untrusted client doesn't receive internal (secret) fields from the database. The client is no longer strongly typed or closely tied to the C# code, so you need a full megabyte of test code that you never would have needed before to validate all the Typescript. This code does nothing of business value. It's a form. You fill it out, and hit submit. There's no "interactivity", there's no single-page-app features used, it's just... waste. Then, then, on top of that, someone that really likes "grand cathedral" style code architecture decided that this whole thing would be more secure if there was a "middle tier". You know, an API. No, not the Angular API facing the Internet! A back-end API. For no reason. For an app written by two developers that has its own, dedicated database, and will never interact with any other app, tool, or system. So now you have to write server-to-server API call code including the DTOs and related definitions, the server code, the client code, the service authentication code, the error handling, the distributed tracing, the HTTP header forwarding (securely!), and on, and on. All typed out by hand, because: "REST is easy!" No wait, there's more: The original architect also wanted to make the system "database agnostic", so the mid-tier repeats every abstraction. It has interfaces, types, etc... so that you can "swap in" another database. This never happened, and will never happen. This is purely wasted effort. Then someone put API Management in front of this. Why? Because the word "API" was used. Remember: Angular uses JSON APIs, not HTML, so it's a "thing" that "needs" management. Then that API management -- a cloud SaaS service -- has a reverse proxy in front of it operating in API management mode for "security". Meanwhile all these layers are riddled with URL injection, SQL injection, and similar basic security errors precisely because it's too hard to add a new field to the form, so developers get lazy and simply add a generic "ExecuteQuery(string sql)" mid-tier method and move on with their lives. This is why we have "too much code". Because architects can't justify their positions if there's only two icons with a single arrow between them in their designs. Because "hip new thing" is a shiny we all love to chase. Because of magical thinking that assumes that more abstractions means the code is more good. We have nobody to blame for this but ourselves.

ChrisMarshallNY 3y ago
That’s a fair assessment, but I guess by “large,” I really mean “composite,” Every large human artifact tends to be quite complex, but is composed of smaller, less complex parts. I don’t see any way to avoid it. In fact, every discipline, other than software development, seems to be managing the complexity (albeit, not always well).
- jiggawatts 3y ago
  I fully agree that composing modules written by independent teams is necessary and good for productivity. We don’t want to reinvent wheels, and layering on top of standard abstractions is generally better even when the fit isn’t 100% perfect. My problem is that if each of those layers is bloated to 5-10x the size and complexity they should be, then we have a problem. This can compound, not just additively but multiplicatively. Eventually you end up in a quagmire where nothing works right and you can’t fix anything because that would just reveal more breakage at layers you don’t control. One thing I noticed over this last week is how much nicer it is to work with something like ASP.NET Core 8.0 instead of the old ASP.NET MVC 5. It’s leaner and meaner, but has enough “batteries included” that I don’t have to drag hundreds of megabytes of slightly incompatible third-party modules in just to get essentials such as JSON and Dependency Injection. As an industry we need to acknowledge the need for cohesive and consistent platforms, not just components. We need to occasionally clean house and consolidate, not just keep throwing packages over the fence and calling it a day.
  - ChrisMarshallNY 3y ago
    > As an industry we need to acknowledge the need for cohesive and consistent platforms, not just components. Agreed, but it's also, apparently, a difficult bar to clear. Apple manages to do it, by having iron-fisted control of the hardware, the operating system, and the SDKs. But even they are starting to fray. I've been writing Apple code since 1986, and I'm getting familiar with some of the newer stuff, like CreateML and SwiftUI. There's a ... difference ... in the way that documentation is being handled. In The Days of Yore, we had Inside Macintosh, which was a multi-volume Encyclopedia Britannica-like set of tomes, delving deep into the operating system and SDKs. It was written by really skilled people; often with advanced and esoteric degrees, and with great writing chops. These days, not so much. I'm glad for bloggers and online enthusiasts.

ChrisMarshallNY 3y ago

That’s a fair assessment, but I guess by “large,” I really mean “composite,” Every large human artifact tends to be quite complex, but is composed of smaller, less complex parts. I don’t see any way to avoid it. In fact, every discipline, other than software development, seems to be managing the complexity (albeit, not always well).

jiggawatts 3y ago
I fully agree that composing modules written by independent teams is necessary and good for productivity. We don’t want to reinvent wheels, and layering on top of standard abstractions is generally better even when the fit isn’t 100% perfect. My problem is that if each of those layers is bloated to 5-10x the size and complexity they should be, then we have a problem. This can compound, not just additively but multiplicatively. Eventually you end up in a quagmire where nothing works right and you can’t fix anything because that would just reveal more breakage at layers you don’t control. One thing I noticed over this last week is how much nicer it is to work with something like ASP.NET Core 8.0 instead of the old ASP.NET MVC 5. It’s leaner and meaner, but has enough “batteries included” that I don’t have to drag hundreds of megabytes of slightly incompatible third-party modules in just to get essentials such as JSON and Dependency Injection. As an industry we need to acknowledge the need for cohesive and consistent platforms, not just components. We need to occasionally clean house and consolidate, not just keep throwing packages over the fence and calling it a day.
- ChrisMarshallNY 3y ago
  > As an industry we need to acknowledge the need for cohesive and consistent platforms, not just components. Agreed, but it's also, apparently, a difficult bar to clear. Apple manages to do it, by having iron-fisted control of the hardware, the operating system, and the SDKs. But even they are starting to fray. I've been writing Apple code since 1986, and I'm getting familiar with some of the newer stuff, like CreateML and SwiftUI. There's a ... difference ... in the way that documentation is being handled. In The Days of Yore, we had Inside Macintosh, which was a multi-volume Encyclopedia Britannica-like set of tomes, delving deep into the operating system and SDKs. It was written by really skilled people; often with advanced and esoteric degrees, and with great writing chops. These days, not so much. I'm glad for bloggers and online enthusiasts.