The Software Architecture Demon
-
I guess I was an old school architect. We typically wrote prototype code for how we wanted to interface with the system, then we went back and designed a system architecture that we could use for those things. We didn't do UML diagrams, or go crazy with patterns, although we had a few singletons. We did use streams between client and server, and that made adding compression a breeze, and later encrypted the compression a breeze. A few lines of code allowed the server to know if the client supported compression and/or encryption. And then it simply constructed the "best" stream object. The clients abilities were known, so it handled what was streamed back. The server was ALWAYS ahead of the client, so it did not have to worry, the old clients NEVER asked for encryption or compression. But I completely agree to a point. I see these complex designs and I wonder. Although I am pretty impressed with most of the RESTful style APIs. QuickBooks Online being the EXCEPTION. Imagine having a Memo Field on an invoice. Imagine Importing an Invoice, that Identifies the Memo field. Imagine NOW that they put that on the CUSTOMER STATEMENT and NOT on the Invoice. No option given to have it be on both or be on the Invoice. Worse, if you have a default Memo defined. And you do an import WITHOUT SETTING the Memo, it does NOT use the default value the way it would if a User Created the invoice. But you can use ANOTHER API call, and set the Invoice Memo Field after it is created. That kind of stuff drives me BONKERS. It's like the programmers have NEVER USED their own system! Google Tasks. Last I checked does not easily let you move a task from ONE task list to another. How swell... You have to copy all the fields, and create a new one, and then delete the other one. God forbid if they add a new field you forget to copy, or the field can only be set AFTER the task is created. LOL... I yearn for simpler days in some ways, and at the same time I pray things keep improving...
Left to my own devices, that's pretty much how I design. The exception is when I'm working with a large team on a huge project. Then the documentation features of UML and the heavy abstractions can *sometimes* be handy.
Real programmers use butterflies
-
I used to be a software architect. I think that's part of why I employ such a jaundiced eye when it comes to layered service architectures and sweeping design patterns just because and drowning in UML because reasons. It's true that when you're dealing with million dollar implementations, multiple deployment points, and disparate teams a lot of this abstraction can be useful. But how common is that in most people's development? I know it is for some of you, sure, but I think you're in the minority, or at least projects like these are in the minority. Not everyone is Plum Creek or Alcoa. It seems like the field of software architecture has taken on a life of its own and coupled with CPU cores to waste and infinite scaling out it has - and i'll just say it - poisoned software development. Just because you know how to do something doesn't mean you should. Most software application architectures do not survive contact with clients plus the erosion of time. They have a shelf life of significantly less than 10 years without some major portion of them being retooled. There are exceptions to this, but designing every solution to be that exception is a waste of time, money and creative energy. I'm also going to come out and say it makes things harder to maintain. When you're working with 20 different classes and interfaces where 3 would do it just increases the learning curve. There are definitely diminishing returns when it comes to decoupling software from itself, and you run into the cost/benefit wall pretty fast. It can only take you so far. It's best not to overdo it. Every fancy little UML entity you drop into your project increases the cognitive load of your project for other developers. Personally, I wouldn't care about that, because "cognitive load" is fun as far as I'm concerned but most people just want to do their work and go home, not spend odd hours studying someone else's work just so they can use it. Keep It Simple Stupid. Whatever happened to that? :sigh:
Real programmers use butterflies