141–150 of 218 posts
Earlier quoted context omitted.
It's pretty rare these days that systems are maintained for that long. More than likely there'll be a rewrite every few years anyway to keep up to date with $EXCITING_NEW_TECH.
Hmm maybe in the Bay Area? Everywhere else I've seen software that is on average a decade old.
Earlier quoted context omitted.
I never went through the over-engineer phase personally. I am a very very lazy person, which leads to me to correct balance most of times: Not enough abstraction, I suffer because of too much change to the code base, too much abstraction, and I feel pissed about my risk management. Since I suffer greatly when I suffer, I avoid suffering in my own code as much as possible. What also helps is that I plan most of my alg…
too much abstraction, and I feel pissed about my risk management Interesting, so it's not a phase for you, but for the rest it sounds exactly like my point, i.e. learning that over-engineering (too much abstraction) is a mistake and as such trying to avoid it.
Glad to see you making progress!
Good 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 ?
I just started grad school this fall (September 2019). My "systems analysis and design" course spends three weeks on UML, Data flow diagrams, and CASE tools. 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.
First 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 joined a company recently that has a simple app for end users to take orders over the phone, perform lookup and refunds. Something that can be built in a few days, seriously. When I looked at the code - WTF!!! The previous dev over architected this thing. Unnecessary layers, interfaces etc. one simple change can take hours.
I think developers need a little bit of management experience to understand the impact of these complexity. At the very end, companies just want something usable to stay in the game...a Honda and not a Rolls.
Earlier quoted context omitted.
Totally. For me just AbstractUserGeneratorFactory does not make sense. You can have a look here to get examples: https://docs.spring.io/spring/docs/3.0.x/javadoc-api/allclas...
It's actually a pretty incredible framework. While it might just look like word soup from that particular vantage point I'd venture to say that Spring Framework is one of the most successful examples of OOP in history. It has massive adoption because of its sheer flexibility which all of those abstract generator factories give it. Granted, I think Ruby on Rails is also an amazing project. For slightly different reaso…
Regarding your comment about the quality of implementation, I agree. This is why I like paradigms that are simple enough for everybody to understand.
I have a hard time understanding the author's point of not using UML but somehow boasting that they used "plain old boxes and arrows" to create "plenty of diagrams". UML is nothing more than a bunch of "plain old boxes and diagrams", but which have concrete, objective meaning that has been specified and thus help share ideas as objectively as possible. UML is a language, and languages are tools to communicate and sha…
The difference is that you can't really use proper UML to quickly explain something on a whiteboard, unless you were fluent in it. I personally get mental inhibitions when I have to quickly decide if the arrowhead needs to be hollow or filled, or if the arrow itself needs to be a line or dotted, or if the box needs to have rounded corners or not... Especially if it doesn't matter for the idea that I'm trying to expla…
That's not true. Class diagrams are boxes with arrows, and so are component diagrams and communication diagrams and deployment diagrams.
If you can draw a box and lines on a whiteboard, you can use UML on a whiteboard.
AFAIK, the only thing that's not explicitly supported in UML is data flow diagrams (i.e., convey the data perspectice instead of describing software components and their interactions).
A big problem IME is people tend to define "simple" as "written in a style I prefer". For example you can extract a series of 10 obviously-related methods from some 2000-line God class into their own class, but have others who are used to a more procedural coding style complain that the indirection is "hard to read" because they need to open a new file. This despite the facts that others find the God class "harder to…
Might be me, but I've always found this a rather strange argument: either they aren't using 'go to definition' which means that to be able to read the other code they have to scroll through the file manually, leaving where they are, and then go back. That's not really convenient? Or they are using 'go to / peek definition' and then it doesn't really matter it's in another file?
Earlier quoted context omitted.
Thanks! I ignored this meaning (not a native speaker). Feeling a bit ridiculous now...
In the spirit of being helpful: “ignored” implies you knew the meaning and intentionally did not address it. I think you meant “I was unaware of this meaning” or “I didn’t know that.”
[1] https://quoteinvestigator.com/2015/04/02/simple/ [2] https://www.age-of-the-sage.org/philosophy/footnotes_plato.h... if you didn't get it already. ;)
> However, no one person owned the architecture or design. The experienced developers did drive this. The lack of formality does not mean a lack of the role. If "experienced developers" are the ones doing the design. They are de-facto architects. > No mentions of microservices, serverless architecture, application boundaries, event-driven architecture, and the lot. Some of these did come up during brainstormings. How…
Central, top-down architecture is extremely political. You have to fight with bigwigs who don't know your problem domain and don't live in your codebase to make it reasonable, or even possible, to solve the business problems on your plate when they inevitably don't fit the 10,000 foot 5-year plan. Pushing down architecture responsibilities into the hands of senior engineers with specific problems to solve / features…