In defense of spaghetti code. *ducks*
-
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 ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, 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 - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
-
I have the impression that OP interchanges 2 things: purpose built single use code, and code with horrible control flow and global data access. I've written code for running on DSPs, on the bare hardware, and everything was purpose coded with a thin hardware abstraction library I made. In my case I had only 16K program memory and 2K RAM. hardware limits aside, when you are programming close to bare metal, it starts to be less and less useful to implement generic frameworks.
-
Solid plan.
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.
-
Wait till you have to modify that code 5 years from now. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, 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 - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
Something I overlooked yesterday is that you have a detailed spec in the form of these "flow diagrams". It's great when it's easy to see how code implements the spec. If that means spaghetti, so be it. Any blame then lies with the spec writer. :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Are you sure you read my OP? Why would I have to modify code 5 years from now that costs $1k-2k to rewrite?
To err is human. Fortune favors the monsters.
Ok, if you want to talk in $s, also post how much did you actually billed (I guess you have an hourly rate)? Then we would agree that it might be cheaper to keep writing spaghetti code. $1k for a full rewrite seems low at a glance... it's less than a working week (in some cases a 1MD)...
Eusebiu
-
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.)
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'. :laugh: 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
-
Something I overlooked yesterday is that you have a detailed spec in the form of these "flow diagrams". It's great when it's easy to see how code implements the spec. If that means spaghetti, so be it. Any blame then lies with the spec writer. :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Well, I don't know... if the spec writer is bad at writing specs, does that mean you need to write bad code? I don't think so... because it's your job to write the code and saying that it's the specs fault, it's a weak excuse. ;) If I see a bad spec, I would discuss this with the writer. Maybe (s)he is junior and does not know/understand the system very well... who knows?!
Eusebiu
-
Jeremy Falcon wrote:
Knowing why this is a bad idea separates the seniors from those who think they are seniors but are not. Even on the off chance you can make sense of spaghetti, in a year or two it'll be harder if you come back to it. If it's handed off to another dev, it'll be harder.
Perhaps I wasn't clear in my original comment, but I tried to be explicit about the low cost of a rewrite. There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense. There's little justification for even spending $500 to again, possibly save $1000 down the road when the downside is that you go dark in terms of client visibility as you're developing the framework in the alternative. Edit: What we have is a fundamental disagreement, which you're trying to paint as hubris, and that's insulting. I think my contributions here speak for themselves, as well as my extensive history of successful development projects. I wish you'd be a little bit more circumspect about what you write here. It would be nice to keep it civil. :)
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
This is not your decision to take; it's the clients/management/call it what you want. You cannot possibly know what's down the road. Ofc, we don't know your contributions - you might be a 10x developer! You don't need to feel insulted if someone says your decision is not of a senior developer - everyone makes mistakes and no one is always right! The thing is that some of the arguments are not adding up... I just wonder why you posted this knowing (because you 'ducked') that this is not common/best practice. Are you looking for validation? :) (you will probably find it from junior developers or some devs that know your project).
Eusebiu
-
Well, I don't know... if the spec writer is bad at writing specs, does that mean you need to write bad code? I don't think so... because it's your job to write the code and saying that it's the specs fault, it's a weak excuse. ;) If I see a bad spec, I would discuss this with the writer. Maybe (s)he is junior and does not know/understand the system very well... who knows?!
Eusebiu
The worst type of spec is one that fails to address all scenarios that are important to a product's behavior. The developer must then ask the spec writer for clarification or decide what to do in such cases. If the flow diagrams cover all possibilities, they pass this key test. But yes, they should be simplified if possible. Reviews really help to avoid bad specs. Just as there are code reviews, there should also be spec reviews.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
honey the codewitch wrote:
There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
Despite needing a diagram? Something isn't adding up. Not sure how many people you've employed before but $500-$1K is a joke. Seems that the diagram would take longer than the code according to you. Which makes no sense. People don't diagram something that takes 1-2 days to develop.
honey the codewitch wrote:
I wish you'd be a little bit more circumspect about what you write here. It would be nice to keep it civil.
I'm not being uncivil. I'm just challenging you. If saying a senior programmer knows why this is a bad idea is being uncivil in your book, then that's just oversensitivity. I could also say that always arguing with people (this is where you say you're not) is also being uncivil. But, this is the Internet. Arguing is a way of life here. This is where you say you're just defending your position. And so am I. But, don't make it seem like I'm a bad guy here because I speak of what a senior should know. But don't worry, this is easily solvable. I'll just stop replying to your click baits. :)
Jeremy Falcon
Jeremy Falcon wrote:
what a senior should know
In general, you are right! He is just arguing that in his very particular case it's better to break the rules (and by better he means time to deliver and money saved, not technical excellence or performance improvements). Unfortunately, he did not paint the entire picture - only the parts that supported his decision. Who knows?! Maybe in his very particular case the decision was correct.
Eusebiu
-
There's spaghetti and there's spaghetti.
if (oldState == "state1" && newState == "state2")
{
}
else if (oldState == "state2" && newState == "state3")
{
}
else if .. else if .. else if .. else { }
// line 1000This may feel like spaghetti, but as long as your code reaches one or more if-statement sequentially and it's readable and you can follow it's not so bad. It's quite easy to refactor, should you ever want to.
public class StateClass
{
public static string oldState;
public static string newState;
}public class DifferentClass
{
//...
StateClass.oldState = "whatever";
StateClass.newState = "something";
//...
SomeControl.Text = StateClass.newState;
}public class AnotherClass
{
private object field1;
//...
private object field90;
//...
if (StateClass.oldState == null) throw new Exception("State not set.");
if (StateClass.oldState == "state1" && StateClass.newState == "state2")
{
SomePublicOrStaticVar = "";
}
else if (StateClass.oldState == "state2" && StateClass.newState == "state3")
{
}
else if .. else if .. else if .. else { }
// line 1000
//...
}Now it's going real spaghetti-like. You'll always have to wonder what will happen everywhere once you set or read either oldState or newState. Also, your code has to run in a specific order, but in different classes so it's not at all obvious or even logical. Not sure what SomePublicOrStaticVar does, but setting it or reading it at the wrong time is sure to mess up something somewhere. Having 90 private fields is also a huge strain on your cognitive abilities. Everything you do in such a class you have to wonder "will this mess up other methods that rely on this field?" Believe me, I know X| I've had code like this mess up Form1 because a user changed something on Form2 (which had no relation to Form1 whatsoever). To me, it mostly comes down to this, how many variables do you have to worry about at any given time and how visible are those variables among your different classes? Large code chuncks aren't the problem (although slicing them up can improve readability and maintainability). Lots of if-statements aren't a problem either, as long as they don't work on too many different (public) variables. When functions have their input and output and nothing else to worry about you can rewrite to your heart's contents if you wanted to and the function may remain a black box if it returns the correct output. I think you're good enough to go for the first spaghetti.
I don't think this is spaghetti code; it's just long and complicated. Spaghetti jumps all over the place and would obscure the actual logic far more than this example does (which is completely hypothetical. Not real world at all, by the way.) Last year I tried a challenge -- to rewrite a hangman game from the late 70's, which was written in an early dialect of BASIC with GOTOs and GOSUBs all over the place, into a modern language. The code was very short, barely a page of A4 when printed out. But to understand this very simple program, I had to print it, and draw lines all over it to work out the program flow, which took over an hour. Imagine if it went to more than two sides of paper! I found a line that was unreachable and would never be executed. Even the person who wrote it wasn't aware. Just a bit of structure, named procedures etc. simplified and clarified it enormously. But I suspect that what the OP is talking about is something a bit different from that. The code may have had a lot of IFs and branches, but writing it in a clear way with meaningful names, rather than abstracting it all to classes, may have been the right call in this instance. But do a reality check: give it to a colleague and see how long it takes them to figure out the flow and logic.
-
The worst type of spec is one that fails to address all scenarios that are important to a product's behavior. The developer must then ask the spec writer for clarification or decide what to do in such cases. If the flow diagrams cover all possibilities, they pass this key test. But yes, they should be simplified if possible. Reviews really help to avoid bad specs. Just as there are code reviews, there should also be spec reviews.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Correct! So, we agree - it's your job to write good code (as well as you can, ofc) even if the specs are bad!
Eusebiu
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, 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 - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
may i please inquire the number of boxes in the flow chart . also the number of lines of code in the final product and the language . if the customer insists on spaghetti one must ask the precise type they prefer . for me it is fettuccini -Best
-
I ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, 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 - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
"assuming not a lot of reuse" is the fulcrum of this kind of decision. Efficiency is using the lowest effort that will get the desired result, so for low reuse, spaghetti is fine. Idk if I could force myself to do it, but then I've been known to use pen and paper, so there's that.
-
While I hear you, I do have one niggling nit to pick with your suggestion that comments *do* have zero impact if you mean they have zero negative impact on your codebase. They do. Comments are extra maintenance, and often get stale. They should be used as sparsely as possible and no sparser. For the most part, code should be self documenting. This is not as true in embedded where you often can't afford the necessary abstractions to express intent, such as using the STL algorithms everyone is familiar with. In the case of embedded comments tend to be more necessary.
To err is human. Fortune favors the monsters.
-
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 ran into an issue recently on a professional embedded project, and that was this: In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code. I chose the latter. Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach. More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client. Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, 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 - or someone else picking up your code). It's all a matter of robbing peter to pay paul. The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on. Flame away.
To err is human. Fortune favors the monsters.
No reason to duck or put the fireproof suit on Honey. In many of our 'real' worlds, time and budget are real concerns, and we don't have the flexibility to create an RFP that rescopes and projects a timeline. It's nice to work in that world, but it's not what the client always wants. Had a case last week where a weird set of changes from an outside vendor (don't get me started on the level of their incompetence with 500+ employees) should have required adding a column to the client's DB and creating the framework and structure to handle the change. Into the thousands of dollars and major timeline. We have two weeks and nowhere near the budget. My colleague was panicking over redesigning everything correctly. I messaged him the meme of the dog with spaghetti on his head and said "time for a nice bowl of pasta". Not pretty at all, but done and in production, working fine. I do know why bird's "nests" look like spaghetti, lol. Your bottom line is 100% correct!
