In defense of spaghetti code. *ducks*
-
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
Eusebiu Marcu wrote:
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
Yes that is how it rationalized. But I have maintained a lot of code. Which means I took it over after the person that rationalized that left. And I do consider the actual cost which is what maintenance is when I am the one that is gone. I also realize that if others were as good at predicting the future as they think they are then they should be investing in stocks and not writing code.
Eusebiu Marcu wrote:
I've never heard anyone saying that it coded that beautiful/maintainable code 'just in case'
Have you asked anyone why they added an abstraction layer when there was only one known case?
-
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.
-
Sorry buddy, but I disagree. There are different levels of good design and for a one- or two-day job, you are 100% correct in the fact we don't have to go full on SOLID, RAII, etc. But that doesn't mean you don't do the basics of a decent structure that should be ingrained in our subconscious by now - especially if it's for work or pay. No senior should and I'd never hire one twice that thought otherwise. Also, there are factors that don't add up. If this quick project was so insignificant, there shouldn't have been a diagram in the first place. Nobody in the industry diagrams anything for a one-day job - nobody. And lastly, if you check out the entire post, you'll notice my points where entirely skipped over too. This whole thread was just clickbait over someone being bored.
Jeremy Falcon
Jeremy Falcon wrote:
If this quick project was so insignificant, there shouldn't have been a diagram in the first place.
Indeed! The thing is that we don't know the full picture - maybe some PO/BA really wanted to have that flow diagram which got complex over time (no one said it was created at the same time with this 'small' change). If the project was already a spaghetti code and the change was minimal (one can debate what minimal is, but since a full rewrite would be 2-3 MD ~$1-2k, I would assume just some functions), then it really doesn't make sense to refactor the whole thing (as small as would be) just for that minimal change. It makes sense if new changes/requirements would come but apparently that's not the case. If the client is fine (assuming that one asks it) with the spaghetti code and nothing will be added in the future, then again, doesn't make sense... E.g. think of a security patch/blocker that is dirty, does the job and can be released in 1h - this scenario I completely understand (I would recommend refactoring but if the client doesn't have the budget - which contradicts the 1k-2k rewrite but anyway... :) - then it's on the client). If OP was part of the original team or at least was asked to change something previously and did not inform the client on the structure, then it's on OP.
Eusebiu
-
Yeah, no it's my decision. The client gets deliverables, and projects designed to spec. I get to decide how to get there in the least expensive way possible, that delivers something robust and to spec. I am not a fan of micromanagement. I work for myself. And yes, I do know the cost of a rewrite, because I wrote the code.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
client gets deliverables, and projects designed to spec. I get to decide how to get there in the least expensive way possible,
Ok but that doesn't mean that is the best decision for the client. The client might pay more to make it cleaner. :)
honey the codewitch wrote:
And yes, I do know the cost of a rewrite, because I wrote the code.
So, as a senior you were fine with writing a spaghetti code from the beginning... Sorry, but that doesn't look like a good decision of a senior... Oh, if you started when you had 1-2y of experience and after 20y you got on the project again, then ok... I can understand that.
Eusebiu
-
It was about a day of work. That's typical for a lot of IoT codebases. You're dealing with kilobytes of RAM and very little room to store code. Projects don't sprawl - they can't.
To err is human. Fortune favors the monsters.
Ok. So, if you won't touch that again and the client takes the responsibility on that, then I can understand that... $500 < $1000.
Eusebiu
-
And if you don't have input/output streams? You have to read the key input directly from the hardware? Even have to debounce the keys yourself, because there's little or no hardware support? We already know (from CP articles) that Honey abstracts displays where possible. Embedded is different.
Alister Morton wrote:
if you don't have input/output streams?
That was just an example. The thing is that since OP said that IT can also be done through some abstractions (which would cost like 1-2k), the only problem is how often would those changes would come in the future. If the client gets to pay him $500 for each change (which will increase if there will be another dev.) vs. $2k + minor fixes to make it maintainable, the client would (in 99% of the cases) ask him to rewrite it (LE: which will make OP look bad as it wrote parts of it already). Now, I understand that embedded is different (to some extent), but good practices are still good practices even in embedded. Again, we do not know the full picture! Only OP and the client know it! :)
Eusebiu
-
Eusebiu Marcu wrote:
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
Yes that is how it rationalized. But I have maintained a lot of code. Which means I took it over after the person that rationalized that left. And I do consider the actual cost which is what maintenance is when I am the one that is gone. I also realize that if others were as good at predicting the future as they think they are then they should be investing in stocks and not writing code.
Eusebiu Marcu wrote:
I've never heard anyone saying that it coded that beautiful/maintainable code 'just in case'
Have you asked anyone why they added an abstraction layer when there was only one known case?
jschell wrote:
I do consider the actual cost which is what maintenance is when I am the one that is gone
Very good! Then you understand the POV of the supporters of practices, clean code, and all those 'buzz' words. :)
jschell wrote:
Have you asked anyone why they added an abstraction layer when there was only one known case?
Honestly, I haven't seen (or I don't remember right now) such a piece of code; could be that one tried to show-off or thought that the project was expanding in the future... who knows!? Also, depends on how one defines "one known case"...
Eusebiu
-
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
-
Ok. So, if you won't touch that again and the client takes the responsibility on that, then I can understand that... $500 < $1000.
Eusebiu
$500 would be roughly the cost of developing an abstraction to despaghetify the code, not to write the code.
To err is human. Fortune favors the monsters.
-
honey the codewitch wrote:
client gets deliverables, and projects designed to spec. I get to decide how to get there in the least expensive way possible,
Ok but that doesn't mean that is the best decision for the client. The client might pay more to make it cleaner. :)
honey the codewitch wrote:
And yes, I do know the cost of a rewrite, because I wrote the code.
So, as a senior you were fine with writing a spaghetti code from the beginning... Sorry, but that doesn't look like a good decision of a senior... Oh, if you started when you had 1-2y of experience and after 20y you got on the project again, then ok... I can understand that.
Eusebiu
The client is on accelerated timeline, and this isn't the final round of development. 5 years from now the software will be completely different, as will the hardware. As a senior dev I'm fine with making any decision that leads to delivering a product on time, that works as specified, and provides the best value. This provides the client value in a way that the abstracted code would not.
To err is human. Fortune favors the monsters.
-
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
Eusebiu Marcu wrote:
and saying that it's the specs fault
Unless of course you are 'writing to spec' then it could be contract violation to do it some other way. But other than that the problem then is not the code but the design/requirements. And it should be addressed at that level. Should be noted that the OP states "so many conditions around state changes" I have seen attempts to make state diagrams into OO and it always looks like idealization run amuck.
-
The client is on accelerated timeline, and this isn't the final round of development. 5 years from now the software will be completely different, as will the hardware. As a senior dev I'm fine with making any decision that leads to delivering a product on time, that works as specified, and provides the best value. This provides the client value in a way that the abstracted code would not.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
I'm fine with making any decision that leads to delivering a product on time, that works as specified, and provides the best value
Again, that's not your decision. YOU don't define the value, the client does. You can make any decisions technically that will deliver the product on time, but that doesn't mean it's the best one for that client - it might me at the current time, but this remains to be seen. Since we don't know the details for the project and your client assumptions, we can only rely on our previous experience which tells us spaghetti code is bad! :)
Eusebiu
-
honey the codewitch wrote:
I'm fine with making any decision that leads to delivering a product on time, that works as specified, and provides the best value
Again, that's not your decision. YOU don't define the value, the client does. You can make any decisions technically that will deliver the product on time, but that doesn't mean it's the best one for that client - it might me at the current time, but this remains to be seen. Since we don't know the details for the project and your client assumptions, we can only rely on our previous experience which tells us spaghetti code is bad! :)
Eusebiu
This client is happier with me than he has been with any developers on his previous projects, teams or otherwise, I'm his MVP - according to him. So, when I have to weigh that against your assessment I come away thinking I'm doing this the right way. My client is thrilled with my work. That speaks for itself. If I was working on a software team, or if I was working with a codebase that was more than a couple of pages long, I would approach it differently. I approach it the way I do based on experience doing embedded, based on my knowledge of this project, and based on the clients expectations and desires. And of all the people on the engineering end of things, I'm the one that has delivered every single time on this project. Nobody else can say that on my team. That also speaks for itself. That's concrete. You're talking principles. That's abstract, and they sometimes don't survive contact with the real world.
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.
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
-
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
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.
-
This client is happier with me than he has been with any developers on his previous projects, teams or otherwise, I'm his MVP - according to him. So, when I have to weigh that against your assessment I come away thinking I'm doing this the right way. My client is thrilled with my work. That speaks for itself. If I was working on a software team, or if I was working with a codebase that was more than a couple of pages long, I would approach it differently. I approach it the way I do based on experience doing embedded, based on my knowledge of this project, and based on the clients expectations and desires. And of all the people on the engineering end of things, I'm the one that has delivered every single time on this project. Nobody else can say that on my team. That also speaks for itself. That's concrete. You're talking principles. That's abstract, and they sometimes don't survive contact with the real world.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
My client is thrilled with my work. That speaks for itself.
That is 99% sure because you focus on financials and time to deliver. :)
honey the codewitch wrote:
based on the clients expectations and desires.
Most likely the client isn't aware what happens if you quit tomorrow. If you would tell them that the code is spaghetti (as you pointed out, not a 3rd party review) they wouldn't be that thrilled, especially if you're their MVP (this means future work) - except, yes, if they decide to scrap the whole thing and start fresh (which can happen though seems a waste).
honey the codewitch wrote:
You're talking principles. That's abstract, and they don't survive contact with the real world.
Depends on how you define real world: in my real world I also work for myself and I don't write spaghetti code and also my clients are happy with the code (sometimes with many abstractions) I write. If you say embedded code is mostly spaghetti code because of this and that (like hardware constraints etc.) I am sure that there will be someone out there to tell/show you otherwise. The post would be been 100x more helpful if you posted the real problem that stops you to implement it in a clean way then trying to search for validation (or for whatever reason you posted).
Eusebiu
-
honey the codewitch wrote:
My client is thrilled with my work. That speaks for itself.
That is 99% sure because you focus on financials and time to deliver. :)
honey the codewitch wrote:
based on the clients expectations and desires.
Most likely the client isn't aware what happens if you quit tomorrow. If you would tell them that the code is spaghetti (as you pointed out, not a 3rd party review) they wouldn't be that thrilled, especially if you're their MVP (this means future work) - except, yes, if they decide to scrap the whole thing and start fresh (which can happen though seems a waste).
honey the codewitch wrote:
You're talking principles. That's abstract, and they don't survive contact with the real world.
Depends on how you define real world: in my real world I also work for myself and I don't write spaghetti code and also my clients are happy with the code (sometimes with many abstractions) I write. If you say embedded code is mostly spaghetti code because of this and that (like hardware constraints etc.) I am sure that there will be someone out there to tell/show you otherwise. The post would be been 100x more helpful if you posted the real problem that stops you to implement it in a clean way then trying to search for validation (or for whatever reason you posted).
Eusebiu
Eusebiu Marcu wrote:
The post would be been 100x more helpful if you posted the real problem that stops you to implement it in a clean way
In this case, what stops me is it costs too much, and doesn't pay for itself. That's what stops me. This is round two of three planned phases of hardware+software development. Phase 1 was reusable. Guess what? The spec changed. That code? Thrown away. Phase 2 is this phase. Delivered at 1/2 the price, more functional, ready to present to the investors. Phase 3 is production. Like I said, I made this decision based on what I know of the project. I stand by it.
To err is human. Fortune favors the monsters.
-
Eusebiu Marcu wrote:
The post would be been 100x more helpful if you posted the real problem that stops you to implement it in a clean way
In this case, what stops me is it costs too much, and doesn't pay for itself. That's what stops me. This is round two of three planned phases of hardware+software development. Phase 1 was reusable. Guess what? The spec changed. That code? Thrown away. Phase 2 is this phase. Delivered at 1/2 the price, more functional, ready to present to the investors. Phase 3 is production. Like I said, I made this decision based on what I know of the project. I stand by it.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
what stops me is it costs too much
I love that you think that these decisions are yours to take! Also, since there is no real reason (beside your view of financials) of not doing refactoring (or doing it right - assuming you don't think spaghetti code is good code) like hardware constraints, did you tell your client that in order to make the code cleaner, more maintainable would cost like $500 more? Maybe he will see this as an investment!
honey the codewitch wrote:
Phase 1 was reusable. Guess what? The spec changed
honey the codewitch wrote:
Phase 2 is this phase. Delivered at 1/2 the price, more functional
Who can tell you that Phase 2 won't have the same fate as Phase 1?
Eusebiu
-
Jeremy Falcon wrote:
If this quick project was so insignificant, there shouldn't have been a diagram in the first place.
Indeed! The thing is that we don't know the full picture - maybe some PO/BA really wanted to have that flow diagram which got complex over time (no one said it was created at the same time with this 'small' change). If the project was already a spaghetti code and the change was minimal (one can debate what minimal is, but since a full rewrite would be 2-3 MD ~$1-2k, I would assume just some functions), then it really doesn't make sense to refactor the whole thing (as small as would be) just for that minimal change. It makes sense if new changes/requirements would come but apparently that's not the case. If the client is fine (assuming that one asks it) with the spaghetti code and nothing will be added in the future, then again, doesn't make sense... E.g. think of a security patch/blocker that is dirty, does the job and can be released in 1h - this scenario I completely understand (I would recommend refactoring but if the client doesn't have the budget - which contradicts the 1k-2k rewrite but anyway... :) - then it's on the client). If OP was part of the original team or at least was asked to change something previously and did not inform the client on the structure, then it's on OP.
Eusebiu
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
-
honey the codewitch wrote:
what stops me is it costs too much
I love that you think that these decisions are yours to take! Also, since there is no real reason (beside your view of financials) of not doing refactoring (or doing it right - assuming you don't think spaghetti code is good code) like hardware constraints, did you tell your client that in order to make the code cleaner, more maintainable would cost like $500 more? Maybe he will see this as an investment!
honey the codewitch wrote:
Phase 1 was reusable. Guess what? The spec changed
honey the codewitch wrote:
Phase 2 is this phase. Delivered at 1/2 the price, more functional
Who can tell you that Phase 2 won't have the same fate as Phase 1?
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.