|
This is the lounge. It's not a programming instruction forum. My post wasn't here to be helpful.
I was simply making an observation about coding practices and how they aren't always applicable. One you clearly don't agree with.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I don't think an honest senior developer would agree with such a coding practice - i.e. spaghetti code - except very specific situations (like legacy, minimal change, etc.) - which do not apply to your post. So, yes, we can agree that they aren't always applicable (especially when no one will use that)  .
You either looked for validation (for whatever reason) or just wanted to waste some time... 
Eusebiu
|
|
|
|
|
The lounge is the proverbial water cooler. If you're posting here you're not working. Whether or not it's a "waste of time" is in the eye of the beholder.
And for the record, I wasn't hired as a senior developer. I was hired as a consultant. So a lot of those decisions you thought weren't mine to make were precisely why I was hired - to make them.
The problem with coming at something from the outside and criticizing it out of the gate is you put yourself in a position where you have to criticize a situation you don't fully understand, and that rarely ends up making one look good, in practice.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I was hired as a consultant
The client might think it hired you as a consultant, but you didn't behave like one as you took all the decisions without consulting with him... that's consulting 101.
But what do we know?! We are not consultants... 
Also, as mentioned 100 times already... I already said we don't know the full picture! But the one you're paint is looking... a bunch of spaghetti. See what I did there?! 
Eusebiu
|
|
|
|
|
You're making a lot of assumptions about what I have and haven't discussed with my client.
I mean, it's fun to write fan fiction, but I think you could find a more engaging topic to tell stories about.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I've asked you already if you discussed with the client or not... if you cannot keep up, just quit!
Eusebiu
|
|
|
|
|
I'd only have a problem with spaghetti code if there was a fairly straightforward way to simplify it (maybe with a table of state transitions) or if it would have to evolve to support a stream of new capabilities in subsequent releases.
I worked on telecom call servers for many years, where spaghetti code made it a pain to work on various products. The problem is hundreds of supplementary services that modify the behavior of basic calls. If some of their logic is inserted into the basic call code, it soon becomes spaghetti. More services were implemented every release, so you also got a bunch of developers all needing to add more spaghetti to that code.
When I was tasked with rewriting one of these products, the design eliminated the spaghetti by separating all of the services' state machines. It used static and dynamic chains of responsibility with observer capabilities, which allowed state machines to be triggered, after which they could override or reuse basic call behavior. I'd write an article about it, but I think the design is overkill for most domains. However, it would likely be very useful when developing software that supports a lot of bidding conventions for contract bridge.
|
|
|
|
|
I'm almost doing that, but I actually have several state machines working in tandem, which, while kind of unfortunate due to the spinning plates factor, was very expedient.
The codebase is small, and a rewrite wouldn't be terribly expensive given how little time it took me to write it in the first place.
I've found with a lot of embedded stuff it's like that. You *have* to keep it small and efficient, so the rules and priorities change a bit as the landscape shifts.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I can make the argument that spaghetti code is the better solution in this case. Creating a general-purpose framework tends to hide the logic. At least when you came back at some future time you only have to understand the spaghetti, and not a framework as well. I think YAGNI and KISS both apply here.
Obviously the answer is different if you're tailoring the spaghetti for multiple solutions.
Software Zen: delete this;
|
|
|
|
|
To me spaghetti code is basically like a messy room you don't clean up. Doesn't mean you need to make a framework, but ya know... at least make the bed.
Jeremy Falcon
|
|
|
|
|
Agreed, but there's a smell when you've got a lot of seemingly arbitrary conditionals and special case handling.
I was assuming that the 'spaghetti' code described by codewitch was what you had left after you'd done cleanup and refactoring.
Software Zen: delete this;
|
|
|
|
|
I don’t remember who said that engineering is the art of knowing when one approximately equal with two and when one is much smaller than two.
Intelligent compromise is at the heart of what we (hopefully) do.
Mircea
|
|
|
|
|
As one guy who was frequent in this fine establishment used to say: "Who needs an OOP when there are copy and paste."
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
My experience is that spaghetti code is usually, but not always, the result of improper factoring with decision making conditionals either too high a level or too low a level. However, this isn't always the case and it appears Honey found one of the exceptions.
Just document the sauce out of it and sprinkle in a little garlic.
|
|
|
|
|
To even admit that I would write spaghetti code knowingly is counter to every fibre in my being.
I was the first in my company, way back when, to be asked what I thought of "structured programming"; i.e. no "go to's". I wrote the first "structured program" and never looked back.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
The spec was spaghetti, so my choice was to design directly to spec, or try to abstract it. I chose the former, and I'm pretty happy with the result. Including coming in under budget.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I've never been over budget. I also don't accept ridiculous schedules.
You can have it fast, cheap, and / or good. Pick 2.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I don't know if I'd say never in my case, but it has been long enough that I couldn't point to a situation where I did.
When I said under budget I mean the project is due on the 10th of next month.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Hmm, not all of us live in that charmed world.
Clients often have line of business needs that eclipse coding purity. They don't care about how it gets done, just that it works reliably. And purity != reliability. In existing codebases, it's often not a matter of bad planning or specs. Sure, we explain the 'do it right' piece, and at the end the result is about the same as me explaining to my dog we can't go for a walk because it's too cold; she still ends up at the door waiting.
|
|
|
|
|
honey the codewitch wrote: More importantly, progress remains visible with the spaghetti approach
Of course.
Ideals should not be applied blindly. They should be followed when they provide benefit.
honey the codewitch wrote: but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly
I really, really dislike the claim that abstractions make anything better when no one can provide any evidence at all that future needs of any sort will be needed. If requirements exist, or a roadmap is known or even if someone expressed a desire for a future feature then maybe consider it. But don't do it 'just in case'.
Doing so it no better than gambling on the big wheel in a casino (one of the worst odds games in play.)
It does not insure any economic future advantage but it does guarantee complexity which future programmers must then maintain (and so must be paid for.)
|
|
|
|
|
You covered something very well here that I was thinking about earlier regarding abstractions paying for themselves.
To err is human. Fortune favors the monsters.
|
|
|
|
|
jschell wrote: dislike the claim that abstractions make anything better
True (in absolute), but in general they help. Indeed, if you just need to print to the standard output, you don't need abstractions (and you don't start with those, ofc) but as soon as some requirement changes that and you will want to do file, on screen, on some API, then abstractions will be better (than, IDK, local ifs, switch even local functions).
jschell wrote: But don't do it 'just in case'
In general (again), you do it because you care about things like clean code, maintainability and avoid cases like 'only God and me knows... now only God'. 
I've never heard anyone saying that it coded that beautiful/maintainable code 'just in case'... while I've heard a lot of times that the developers were not aware of some clean code principle or did not know how to really implement it.
Eusebiu
|
|
|
|
|
Hard to say. I've inherited code that was overly abstracted and it can be a dog to read. That said, it can be challenging up front to determine the correct level of abstraction. I have seen few perfect waterfall designs, most push agile to a new definition So, defensively you include the parts and pieces.
I've gone back at the end and removed some since the flat procedure was clear, direct, and less code; and never called by anything else.
|
|
|
|
|
MikeCO10 wrote: That said, it can be challenging up front to determine the correct level of abstraction
Yes but that is hindsight. It applies to everything in the world.
One should not arbitrarily apply abstractions because one time they had to maintain a 20 year legacy app where abstractions were not added on day zero.
That is not to say that you get to ignore the roadmap when you design the application now.
|
|
|
|
|
jschell wrote: One should not arbitrarily apply abstractions because one time they had to maintain a 20 year legacy app where abstractions were not added on day zero.
True, but apparently (if you read other posts) OP created it (or some parts of it): he wanted to optimize the financials in the detriment of technical (which in general will bite back sooner or later).
Eusebiu
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
