Software Architecture Is Overrated, Clear and Simple Design Is Underrated
131–140 of 218 posts
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#132Earlier quoted context omitted.
In my own experience, it's really a must to go through both over- and under-engineering phase yourself: only then I found I got a really clear view on what's good and bad in approach, allowing me to default to somewhere in between (with outliers when useful) and in any case with focus on simplicity (but again, if needed for e.g. performance that can be violated). All of this is the basic 'learn from your mistakes' pr…
I don't even think it's a phase. From what I see in my own experience, overengineering comes from not having a deadline to deliver an actual working piece of software. Unclear requirements. Fear that the code must be perfect against change without knowing what the changes might be. Underengineering comes from confidence that the issues are too small to worry about. Or the time constraints mean I can't try to find goo…
Not doing so, time required for maintenance will increase, and competing with new feature development time. Of course these new features have deadline already to short even before you add this burden. Moreover, maintaining everything working is the top priority "right now", but making the new development reaching production is prevent the solution to fall into market irrelevance.
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#133The value of Enterprise Architecture doesn’t come in to play until you’re an actual Enterprise. We operate more than 300 IT systems, from a myriad of different and switching (courtesy of procurement) suppliers. These systems are operated by 5000-7000 employees, and range from making sure employees get paid and patients get the right medicine to simple time booking apps. Most of these systems need to work together, an…
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#134First 1-3 years of coding, I just coded to get sht done. I got a lot of sht done. Next 4-8 years, I started getting cute with it and applied all kinds of design patterns, Factory, Abstractions, DI, Facade, Singleton you name it. It looked cute and felt good when it all worked but it was a juggling act. There was usually like 2-3 files to touch just to do one thing. UserFactory, UserService, UserModel, User, you get t…
Well yes. It all sounds all so easy when you put it like that. The problem is that, in my experience at least, you can’t just teach junior engineers how to go straight to phase 3. You have to go through phase 1 and 2 to really develop a sense for what makes a solid, streamlined design. Some never get there - either because they become set in their ways early, or because they work in organizations where the wrong kind…
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#135Confusing methodology with architecture is not helpful. Even the simplest system has 'architecture'. Now this can be arrived at via: happenstance methodology, or expression of internalized well known types, or via a more formal process.
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#136First 1-3 years of coding, I just coded to get sht done. I got a lot of sht done. Next 4-8 years, I started getting cute with it and applied all kinds of design patterns, Factory, Abstractions, DI, Facade, Singleton you name it. It looked cute and felt good when it all worked but it was a juggling act. There was usually like 2-3 files to touch just to do one thing. UserFactory, UserService, UserModel, User, you get t…
> I realize I code a lot slower now than in the past and that I write much fewer lines of code. It’s both good and bad because sometimes I’d even spend hours just trying to properly name a variable. I think the important thing happening here is more than just naming. You’re taking the time to fully consider what you’re doing with the new variable in order to name it. That’s time very rarely wasted.
- how much time will the code be reread?
- does the carefully selected name does make sense for other readers, future self included? That is, does it help to make things easier to understand for them?
- a good name can be reused extensively over your whole career, so a few hours might well be well invested time from this perspective if you plan to keep a foot in the technical side of the story all along. Actually, a good name is surely something you might have the opportunity to reuse outside a coding context.
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#137Earlier quoted context omitted.
Not OP but couldn't you split up you project to smaller projects? >> But when you get past a certain size actual architecture becomes very beneficial. This article and only rejects the convoluted architecture approach with design patterns and suggests that you can come up with your own design without using these. It is not arguing that there is no need for architecture at all.
>Not OP but couldn't you split up you project to smaller projects? My own personal stuff I can do whatever I like with, work stuff I don't have much say over. Could they be split up? Oh, yes. Does it need to be 1 million lines of code? No... I think it could probably be about 1/5th to maybe even 1/10th of that. But still, even if it's split into microservices or just smaller modules, the aggregate lines of code requi…
Way too many (but not all) enterprise codebases can be divided into small non-interacting pieces that share only a small bit of code. If so, diving them transforms the problem from a monster program that nobody can ever understand into a lot of tractable ones that a single person can read.
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#138In my career thus far, I can honestly say I've never, ever, ever seen an "Architect" who actually provided valuable inputs. Not trying to say they don't exist, but I've just never witnessed someone with that title actually have a positive impact on any project I've worked on. The only semi-positive value I've seen an architect have is when they counter another architect to allow the engineers get on with their work w…
We have a great architect right now, but he's really just an engineer designated as the "architect". He also codes sometimes.
Why is anyone assuming that an software architect is not supposed to be a software engineer?
The software world is not divided as the civil engineering world, where architects are responsible for meatspace UX and engineers are tasked with bringing the UX to life.
In the software world, software architects are expected to be experienced software engineers who are tasked with coming up with design decisions upfront that render the software development project feasible and economical by picking which technologies to reuse, which modules/services to develop independently, and how to run in production.
Which of hear tasks is not the job of a software engineer?
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#139Good article but some parts are outdated like who uses UML these days ? Saying you did not create diagrams using any architecture tools is but obvious, no ?
This would have been a great course, 20 years ago. No sane business uses these tools today. The military might, but that's about it.
Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated
#140Design is part of architecture so it doesn't make to compare them. The best architectures are usually the simplest ones which get the job done. To design the simplest architecture possible, you need to know exactly what "get the job done" means. Many software architects have no vision when it comes to seeing all possible use cases for the product so they don't know what are the minimal structural requirements. So eit…
http://agilemodeling.com/essays/barelyGoodEnough.html
I think too many people want to apply a "silver bullet" to all projects: IoC, Docker containers, auto-scaling, etc. But sometimes I'm just tossing data from an API into a database somewhere. I don't need all that complexity.
Other times, I'm building an enterprise product with three fully-staffed agile teams, spending a million dollars annually for five years. Architecture that enables those teams to work in a cohesive way becomes very important, so an IoC pattern might save us a lot of time down the road.
Great architects know when to underengineer and when to overengineer.