|
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
|
|
|
|
|
Eusebiu Marcu wrote: OP created it (or some parts of it): he wanted to optimize the financials in the detriment of technical
Actually I did read the rest of it.
The author is a contractor doing piece work. This is not part of a large application for a company for which the author is working as an employee.
So yes optimizing the cost is significant because increasing the cost might mean a cancelation of the contract which would impact both parties.
|
|
|
|
|
jschell wrote: The author is a contractor doing piece work. This is not part of a large application for a company for which the author is working as an employee.
This does not mean writing spagetti code over and over again. The ONLY reason he states is the short-term cost (as he thinks the app will be scrapped) - no hardware limitations, no legacy code, no nothing... only short-term cost. Doesn't really matter the size of the app; writing spagetti code over and over again will cost more to maintain in mid/long term (especially, if a new dev picks it up) not to mention the unknown side effects a change might have.
jschell wrote: optimizing the cost is significant
Is significant if you also consider the time scale + code's future. If it would have been better to write spaghetti code as a best practice, it wouldn't be a bad practice. 
I never encountered an app that was badly written (like spaghetti code) and kept alice just because in the initial stages the cost was peanuts, because most likely after some short time the cost of having that app will exponentially increase...
Eusebiu
|
|
|
|
|
Eusebiu Marcu wrote: I never encountered an app that was badly written (like spaghetti code) and kept alice
How long have you been doing this? How many companies have you worked for?
In my experience, midsize companies that have been around for a while, always have legacy code bases that are a mess. Code that never runs (probably), applications and documentation that no one understands, code that is so fragile that developers fear to touch it, very odd data models, etc.
Larger companies can undertake the cost of complete rewrites not because they want to but rather because the mess which cannot piecemeal optimized anymore is impacting the bottom line right now and the road map calls for much more traffic.
|
|
|
|
|
jschell wrote: How long have you been doing this? How many companies have you worked for?
If you quote me, at least quote the entire sentence.
I said: "I never encountered an app that was badly written (like spaghetti code) and kept alive just because in the initial stages the cost was peanuts". In all my apps, they were always written with a strategy in mind (and there was never such a thing: write it as you like, we will scrap it later, which OP is basically saying and insisting on why spaghetti code is a "solution" - it might be in this weird case...), they knew that it would be at a certain standard, so no spaghetti code even if it was the cheapest solution. The point was that the initial cost was not the reason to keep it for later. Oh, that it had become so useful/critical (because someone didn't do it's job to review the code or hired the wrong devs or didn't want to change it anymore because was cheap and thinks will never change, which it's actually the counter-example of what OP is saying) that one cannot easily replace it, yes, ofc I've encountered; hell, I helped refactor them but the company never said "it was a cheap app, how can we not support it now?".
To answer your questions, I worked for both mid-size companies and corporations, and for about 17 years (one can say I have a little of experience in software development, in multiple languages, and runtimes - from native, to managed to gaming). You are right that larger the company, the easier is to "decide" to rewrite it, but no "normal" company (I don't know them all) would decide that (i.e. keep it just because it was cheap the first 2-3 sprints ).
Eusebiu
modified 22-May-23 4:47am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
