|
honey the codewitch wrote: not spend odd hours studying someone else's work just so they can use it.
Most don't bother with the "understanding" bit at all: Stack Overflow Patchwork | CommitStrip[^]
Go to QA and look at how many people want code converted from C++ to Python (or vice versa) so tehy can hand it in, or want trivial code explained to them. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Most of my code goes directly into (ASP.NET Core) Controllers and PageModels nowadays.
I have a Core project, which has code shared between all my projects and a SqlServer project for my database stuff.
Then a Services project which has some common services, like Smtp, some Azure stuff, etc.
All injected using the default .NET Core DI library.
Sometimes I think, maybe I'll need this piece of code in another page later on, but then I ignore that thought.
When (if) I actually need to re-use that code it's just a minor refactoring to move it to the Core, SqlServer or Services project.
I recently made some NuGet packages for functions I use over and over in different projects.
I'm also not concerned with keeping my copy/pasted functions up-to-date in every project anymore.
It works in older projects in its current state, so no need to "fix" what isn't broken there.
And that's how I roll nowadays, KISS and YAGNI 
|
|
|
|
|
It sounds like you've got a good handle on things. 
Real programmers use butterflies
|
|
|
|
|
If only
Been hurting my brains over some stupid .NET Framework Azure AD Authentication thing all day and I've got nothing.
I even asked a question in Q&A about it, first one since 2018 
|
|
|
|
|
That's just coding.
Just last night I had to
1. Determine why a driver was randomly dropping characters from strings printed to a screen, but only if they were small text. Turns out the driver wasn't tested very well with my hardware and i had to modify the timing of it.
2. Determine why text wasn't displaying after i put a solid white background on it. I have to draw it twice. I still don't know why. See also, dodgy driver.
3. Implement my own HTTP chunked encoding scheme just so I could bulk upload some JSON from a machine with a total of just over 500k of ram. Worse, I had to timestamp my uploads with a valid date time but my machine has no clock. I was ... creative.
#1 and #2 sent me to some forums to post questions for which I got no answers.
#3 simply took hours.
That's just development, so when I say you've got a good handle on things I still think you do.
Your machine isn't on fire, you're not going bald from stress, and you're not seriously contemplating a career in pizza delivery if you make it out of this project alive. You're fine. 
Real programmers use butterflies
|
|
|
|
|
I went from pizza delivery to coding! And there were times I wished I'd never left! 
|
|
|
|
|
|
You've downloaded my code before, silly. So of course I am always watching you. Through your computer.
What the hell did you think most of those "parsers" actually were anyway? Why else would I write 20 incomprehensible but nevertheless popular projects for people to download? Spyware, my good man. The money is great.
By the way, reset your passwords.
Real programmers use butterflies
|
|
|
|
|
I know for a fact that's not true.
The horrors you'd have seen on my computer would've left you blind and unable to type that message 
Many a ransomware criminals have paid me to let them unlock my computer 
On the other hand, you use braceless if-statements and I can't think of more unspeakable abominations than that 
|
|
|
|
|
I have spent some time spelunking the depths of coding depravity it's true, but just look at these gems I've found!
my precious!
Your computer is tame. I don't even see a dodgy and outdated copy of GRUB in your bootloader code. Where is your sense of adventure?
Real programmers use butterflies
|
|
|
|
|
Ok, you've convinced me, changing my passwords now
|
|
|
|
|
honey the codewitch wrote: not spend odd hours studying someone else's work just so they can use it
Part of the architecture is to structure the system, or the code, exactly so that people who want to do this can do it, and are not bothered with higher level topics.
honey the codewitch wrote: I'm also going to come out and say it makes things harder to maintain
No. Over-engineered code or undocumented code is hard to maintain, whether it has been created based on highly sophisticated design patterns and architecture principles or "by hand", but you cannot say that using architecture design always makes code harder to maintain. 15 year old multi threaded spaghetti code resulting from a 15-year-old-company-time one guy developer show is hard to maintain. Always.
Actually, UML or SysML are tools, and as every tool, they should be used adequately to fulfil a certain purpose to make sense. I agree that using a tool just because you can is not a good strategy, but on the other side and like any tool, they can come very handy if well used.
|
|
|
|
|
Good post. I will add that I only find UML diagrams useful for documenting an architecture once it is stable. Maybe there's something wrong with me, but I've never laid out an architecture that didn't change once the code started to speak. Often I just start coding and refactoring, and it's probably because software has to grow organically. Bottom-up and side-to-side are as much of that as top-down. The static analysis tool that I developed was written without any up-front design, just diving in and starting on a recursive descent parser.
|
|
|
|
|
I agree to a point.
Rage wrote: Part of the architecture is to structure the system, or the code, exactly so that people who want to do this can do it, and are not bothered with higher level topics.
This is how it should be. In my professional experience it was sometimes the case that a software project would be designed appropriately for its size and the team situation. In many cases, it simply wasn't. People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death.
Is it as common as badly designed or simply undesigned software?
No.
Is it destructive and harmful to projects?
Yes!
I guess to sound cliche it's about moderation. You have to make the design appropriate for a project.
I'm not dismissing UML entirely either. But it's is one of those things that strikes as having the perception of being far more useful than it actually is.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: You have to make the design appropriate for a project
Agreed, and this exactly is what should be (also) taught in CS courses.
|
|
|
|
|
honey wrote: People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death.
Wow. I guess the world has changed since I last had a salaried job, because I only saw this twice in over 20 years. The second time, I realized what would eventually happen, so I transferred to another group and built the appropriate subset of the same thing that a team of 30 or 40 were working on.
|
|
|
|
|
I was a software architect and consultant working primarily in project rescue. I came across all kinds of trash fires.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time.
There are also people who religiously follow a template procedure for coding, irrespective of how the project is currently organised.
For example, in a project which uses OOP practices - so normally if you have a Widget id and want the Widget object, you'd call the static method Widget.Find(id) - I've worked with people who write an IWidgetFinder interface, then a WidgetFinder class with a constructor which takes a delegate function to handle errors; so when it's called you first instantiate the WidgetFinder with the error handler, then you can call WindgetFinder.Find(id)!
All this repeated for dozens of trivial functions with interfaces which are only ever going to be used by one class and classes that are only used from one place in the project with the same error handling that's used everywhere!
And, in this project, much of the time the end result comes down to an EF call like...
DBcontext.Widgets.Where(w => w.id == id).First();
|
|
|
|
|
YES! This kind of thing. It's unnecessary. Code should be as simple as it can be and no simpler.
Real programmers use butterflies
|
|
|
|
|
Thing is I hardly ever see development task that you could do and "not be bothered with higher level topics".
From my experience, you have vertical integration in the system from fronted to database and to implement a feature that is useful for a user you have to have insights in all those layers.
Of course there are some local fixes, but usually you affect some other part anyway. For most of other stuff you have to have insight what user will do, what business wants to achieve, what is general direction of a system architecture.
|
|
|
|
|
Ever worked for embedded world (with multiple layer ofSW from different companies) or for DoD (where SW developer A does not know what the guy sitting next to him is coding for) ?
|
|
|
|
|
I worked in a couple of places but maybe because I would not fit in "just code that, no questions asked" approach I am biased.
|
|
|
|
|
Quote: 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.
I would be very careful with the "3 would do it" part. SRP should always be respected otherwise you will get burned really bad sooner or later. I agree that overdesign is a waste of resources, yet underdesign tends to cause much more damage. If you design something with hundreds of entities and expect it to remain maintainable for 5+ years, initial investment into architecture pays off. Of course, if the architect is well familiar with both application architecture practices and the domain of the application.
|
|
|
|
|
Niemand25 wrote: agree that overdesign is a waste of resources, yet underdesign tends to cause much more damage.
I'm not advocating for doing away with the design phase. I also think that while what you say is true, people are also taught this heavily, and I think they take too much to heart. Maybe that's what it is too? Maybe people get so afraid of a deathmarched project that they overengineer everything?
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
