In defense of spaghetti code. *ducks*
-
And that makes sense, doing what you did. For starters, the code was in use for 20 years. One thing I didn't mention in the OP and perhaps I should have, is this isn't the final development phase. We deliver in stages. We're on stage 2, right now, with a 3rd one planned at the very least. At worst this means coming back to this particular code and starting over, but experience tells me, when I made the 1st iteration a bit cleaner, I had to rewrite it anyway because the spec changed so much. So it's a risky maneuver, investing in cleaning this up. Worst, like I said, it means "going dark" for a bit while I develop a framework that may or may not even be used on the 3rd round.
To err is human. Fortune favors the monsters.
Thanks for backing me up on that ... These decisions we make can cost a lot of time, going into years, so we have to be spot on. Great Post!
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
That's a ton of assumptions, but I can promise you that nobody wants to flowchart anything insignificant. And no client will be ok with spaghetti or crap code. Try asking one...
Jeremy Falcon
Indeed! My question exactly to the OP... he didn't bother to answer it because the answer is obvious! I guess the client had some bad luck with some previous devs and now he trusts him completely since he's delivering an end result to some expectations, not knowing what's underneath mainly because it thinks/hopes that whatever comes next doesn't need whatever OP is delivering... which is kind of stupid but who knows... LE: and you know what will happen? After the investors will give them some money, the client will not agree a refactoring/recoding (because it works! why should we rewrite it?!) and OP will either quit or work on his free time... :))
Eusebiu
-
Eusebiu Marcu wrote:
I love that you think that these decisions are yours to take!
I love that you think you can tell me how to do my job. When you're signing my checks, you can tell me what decisions I can make. Otherwise, your opinion and $7 USD will buy you a latte.
Eusebiu Marcu wrote:
Who can tell you that Phase 2 won't have the same fate as Phase 1?
I expect that it will, since the product has not been finalized in design yet. That's why it doesn't make sense to gold plate it with abstractions that will never pay off.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
I love that you think you can tell me how to do my job.
That's the thing! I am not telling you to do anything; on contraire - I am trying to help you understand that the road you took might not be beneficial for you and even tried to come up with scenarios where your decision makes sense (which you proved wrong one after the other... that's life!). Honestly, it seems like you hide a lot of decisions from the client because you (think) know better! That's generally dangerous! But keep going and see where this leads you!
honey the codewitch wrote:
will never pay off
In general it's... not good to say *never*! I still wonder why you posted this, as it's not really a discussion since your answers are like "I have experience", "I know better", etc. So, seems more like a clickbait than something really useful which actually proves the general rule.
Eusebiu
-
honey the codewitch wrote:
I love that you think you can tell me how to do my job.
That's the thing! I am not telling you to do anything; on contraire - I am trying to help you understand that the road you took might not be beneficial for you and even tried to come up with scenarios where your decision makes sense (which you proved wrong one after the other... that's life!). Honestly, it seems like you hide a lot of decisions from the client because you (think) know better! That's generally dangerous! But keep going and see where this leads you!
honey the codewitch wrote:
will never pay off
In general it's... not good to say *never*! I still wonder why you posted this, as it's not really a discussion since your answers are like "I have experience", "I know better", etc. So, seems more like a clickbait than something really useful which actually proves the general rule.
Eusebiu
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.
-
Thanks for backing me up on that ... These decisions we make can cost a lot of time, going into years, so we have to be spot on. Great Post!
If it ain't broke don't fix it Discover my world at jkirkerx.com
Well, that's the thing! His decision is a bad one (statistically) and hopes that the next phase will pay for the this one because he always thought there will be no other or the changes will be so big that the client will agree with a new code. Do you still think he was spot on? :laugh:
Eusebiu
-
Well as long as it's clean spaghetti code with comments, then I'm OK with that. But on the flip side, I just spent a couple of years translating/re imagining code and HTML that was beyond spaghetti code in PHP 4.2 to PHP 8, where you have SQL statements buried in HTML, with one comment, "Grace fixed the login" on many of the web pages. 3 different programmers that went to UC Irvine, with 3 different styles of programming. And what made it so bad was simply nomenclature and haystacks, where the 3 different programmers didn't name the variables consistently, with one variable that still eludes me, "session_origin". These 3 kids went back to China in 2008 after graduating, and left the customer with a lump of coal, but it worked for 20 years. I choose the long process of making it clean, highly organized with reusable code, and everything commented, so the next person can work on it. But I had to tell the customer many times that what they want is too expensive, and that it would blow their budget so fast, stick to the meat and potatoes first and lets get it up and running.
If it ain't broke don't fix it Discover my world at jkirkerx.com
That's exactly what OP is doing! He keeps the price/cost low by writing spaghetti code, hoping that the client will agree with a new code which will contain (guess what?) abstractions :laugh: or the spec will change so much that it will make the code obsolete. You, on the other hand, were at least honest and told the client the reality! The fact that they had the experience with the 3 devs which delivered a bad quality software (in development terms) which now will cost the client multiple times the initial estimate just proves that bad software will always be bad. Ofc it will not agree with your estimates if it had that experience with the peanuts developers and working software (which is exactly the same as the current OP phase - the only difference will come in the case the investors/client will not use the code anymore and then he optimized $500 and the client invested many thousands or tens of thousands)! :laugh:
Eusebiu
-
Well, that's the thing! His decision is a bad one (statistically) and hopes that the next phase will pay for the this one because he always thought there will be no other or the changes will be so big that the client will agree with a new code. Do you still think he was spot on? :laugh:
Eusebiu
My decision would be a bad one if I was writing business software on a team, for an enterprise. Fortunately, I found work that pays better and isn't mind numbing. But the priorities are different. If I was making bad decisions I wouldn't be nearly as successful as I am. I think you have an unrealistic view of your own position and how "right" you are.
To err is human. Fortune favors the monsters.
-
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.
It's not "spaghetti code", it's "Flow Diagram code". An easy 1:1 direct conversion. As long as the customer continues to use a Flow (aka State) Diagram as the documentation, then it's Knex spaghetti for the win! Naming the `goto` junction points is hard, but then naming is hard anyway. Customer is likely to adopt your naming anyway if they haven't already named things (states) :rolleyes: .
-
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) :doh: . You either looked for validation (for whatever reason) or just wanted to waste some time... :)
Eusebiu
-
It's not "spaghetti code", it's "Flow Diagram code". An easy 1:1 direct conversion. As long as the customer continues to use a Flow (aka State) Diagram as the documentation, then it's Knex spaghetti for the win! Naming the `goto` junction points is hard, but then naming is hard anyway. Customer is likely to adopt your naming anyway if they haven't already named things (states) :rolleyes: .
I'm inclined to agree with this. That said, I still feel spaghetti applies in as much as the code jumps around, and sometimes fires off one thing, which causes another thing, which makes the final result. It's hard to follow without a diagram.
To err is human. Fortune favors the monsters.
-
My decision would be a bad one if I was writing business software on a team, for an enterprise. Fortunately, I found work that pays better and isn't mind numbing. But the priorities are different. If I was making bad decisions I wouldn't be nearly as successful as I am. I think you have an unrealistic view of your own position and how "right" you are.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
My decision would be a bad one if I was writing business software on a team, for an enterprise.
Not necessarily - writing good software requires skills - you might not have them, for all we know (and ofc we don't). But so far the ONLY argument that you gave is cost (having the hope the final decision will be to scrap the code). Well, for that simple thing you shouldn't write the OP - I wrote it in less than 20 words... :laugh:
Eusebiu
-
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) :doh: . 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:
My decision would be a bad one if I was writing business software on a team, for an enterprise.
Not necessarily - writing good software requires skills - you might not have them, for all we know (and ofc we don't). But so far the ONLY argument that you gave is cost (having the hope the final decision will be to scrap the code). Well, for that simple thing you shouldn't write the OP - I wrote it in less than 20 words... :laugh:
Eusebiu
If my profile here was good enough to get me scouted professionally, it's good enough here for you to assess my skills. I think it's height of hubris to turn a disagreement about practices into a referendum on your debate opponent's skills in the field. David Dunning made his career off people who engage in nonsense like that, but you do you. :)
To err is human. Fortune favors the monsters.
-
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... :wtf: 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?! :laugh:
Eusebiu
-
I'm inclined to agree with this. That said, I still feel spaghetti applies in as much as the code jumps around, and sometimes fires off one thing, which causes another thing, which makes the final result. It's hard to follow without a diagram.
To err is human. Fortune favors the monsters.
It's a 'source of truth' problem. A well labelled complete flow diagram pre-defines the structure. Meanwhile a rambling weasel word requirements document is, well, rarely complete, even conceptually. So, for A very comprehensive and precise spec | CommitStrip[^] ...
-
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... :wtf: 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?! :laugh:
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.
-
If my profile here was good enough to get me scouted professionally, it's good enough here for you to assess my skills. I think it's height of hubris to turn a disagreement about practices into a referendum on your debate opponent's skills in the field. David Dunning made his career off people who engage in nonsense like that, but you do you. :)
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
David Dunning made his career off people who engage in nonsense like that
Indeed, like everything you write, as you correctly pointed out, is nonsense (dude, your words, not mine!). :laugh: Now I'm just having fun with you - it was clear like 5 posts ago that you cannot be 'brought' on the straight path - and the fact that you said you are not a senior developer but a consultant, it's precious! :laugh:
Eusebiu
-
honey the codewitch wrote:
David Dunning made his career off people who engage in nonsense like that
Indeed, like everything you write, as you correctly pointed out, is nonsense (dude, your words, not mine!). :laugh: Now I'm just having fun with you - it was clear like 5 posts ago that you cannot be 'brought' on the straight path - and the fact that you said you are not a senior developer but a consultant, it's precious! :laugh:
Eusebiu
Ah condescending stuff! Real professional. I'm not going to continue this, because I have standards for the types of discussions I'm willing to engage in. You have a great day!
To err is human. Fortune favors the monsters.
-
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! :laugh:
Eusebiu
-
Ah condescending stuff! Real professional. I'm not going to continue this, because I have standards for the types of discussions I'm willing to engage in. You have a great day!
To err is human. Fortune favors the monsters.
:laugh: :laugh: :laugh: Your words, dude, your words! I just pointed them out... You are too sensitive for a consultant! The same with that remark earlier from the other guy that pointed out that some think they are senior but really are not...
Eusebiu