In defense of spaghetti code. *ducks*
-
jkirkerx wrote:
The way I see it, if your selling $18M of construction jobs a year, $250K+ is a small price to pay to confirm your not losing money.
As always, depends. If they would have seen it as you did, then yes! If they still trust the old guys, then... no! :)
jkirkerx wrote:
Was the ops decision based on code and best practices, or was it a decision based on best business practice
After a long discussion the ONLY (like the only one and no other, especially technical - don't know why he mentioned embedded... I guess to build some sort of aura over it) argument OP came up with was financials with a little bit of narcisism (I am the only one that delivers on time/on budget, I know better the project etc.; ofc, there are other points of discussions since he said he coded from the beginning which raises other questions but will ignore those), thinking that whatever he build now will be scraped in the future (because phase 1 was scrapped) and redone correctly when the real money comes in. At a high level, it makes sense if you are sure of that outcome though why would someone pay you once to write some bad code (that works nevertheless) and then pay you again to write the good code? I can understand that phase 1 might have changed so much... but also phase 2? :wtf:
Eusebiu
Eusebiu Marcu wrote:
(I am the only one that delivers on time/on budget, I know better the project etc.;
I hear that from my car mechanic friend that works at a Porsche dealership. And my construction contractor friends as well. It is a pretty important track record to keep, as a contractor being considered for hire. I pay myself first, 2 hours a day 7 days a week, to learn some new skills. First being economics, 2nd - How money really works, 3rd - how to invest and manage my investments and assets, and now Rich Dad Poor Dad, 2 chapters left, learning the difference between assets and expenses, how the rich stay rich. Overall in the end, the op is on his journey of learning and mastering his skills, trying to get to the next level which usually leads to higher pay or salary, and a higher quality of life, and I can appreciate that. But one day he will have to figure out the money part, like take a step back on this skill and open the door to another skill that he can use personally to enhance his wealth. After reading Rich Dad Poor Dad, my new training says to offer respect to the op, and perhaps just offer better guidance if he's willing to learn.
If it ain't broke don't fix it Discover my world at jkirkerx.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.
While I have written, or tried to write, well-structured code for over 45 years, there was a time when I had no choice. I was dealing with making changes to the mainframe operating system, a beast in which the non-resident portions were in pages of 384 memory words in length. This was in the days when a 64K machine was considered fairly large. Not only was it spaghetti code, one of the standard tricks was to overwrite the memory used by the housekeeping and initialization code in order to use it as storage. After all, if that code was only ever executed once, then after it ran it was simply occupying space for no good reason. This, of course, was all done in assembler, and predated the use of read-only memory, so writing self-modifying code was not only de rigueur, it was a talent you had to learn and be good at. Little of that code ever got well commented, but that was the way we rocked.
-
While I have written, or tried to write, well-structured code for over 45 years, there was a time when I had no choice. I was dealing with making changes to the mainframe operating system, a beast in which the non-resident portions were in pages of 384 memory words in length. This was in the days when a 64K machine was considered fairly large. Not only was it spaghetti code, one of the standard tricks was to overwrite the memory used by the housekeeping and initialization code in order to use it as storage. After all, if that code was only ever executed once, then after it ran it was simply occupying space for no good reason. This, of course, was all done in assembler, and predated the use of read-only memory, so writing self-modifying code was not only de rigueur, it was a talent you had to learn and be good at. Little of that code ever got well commented, but that was the way we rocked.
We called that overlay programming. You planned your design to allow for the orderly reuse of memory. One could have a program that used 5x the memory you had available. It wasn't like virtual memory where the hardware made all of that transparent, but it accomplished the same basic job except you were in control of when and what overlays were called into memory. The main or parent program was always in memory.
"A little time, a little trouble, your better day" Badfinger
-
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.
-
Eusebiu Marcu wrote:
(I am the only one that delivers on time/on budget, I know better the project etc.;
I hear that from my car mechanic friend that works at a Porsche dealership. And my construction contractor friends as well. It is a pretty important track record to keep, as a contractor being considered for hire. I pay myself first, 2 hours a day 7 days a week, to learn some new skills. First being economics, 2nd - How money really works, 3rd - how to invest and manage my investments and assets, and now Rich Dad Poor Dad, 2 chapters left, learning the difference between assets and expenses, how the rich stay rich. Overall in the end, the op is on his journey of learning and mastering his skills, trying to get to the next level which usually leads to higher pay or salary, and a higher quality of life, and I can appreciate that. But one day he will have to figure out the money part, like take a step back on this skill and open the door to another skill that he can use personally to enhance his wealth. After reading Rich Dad Poor Dad, my new training says to offer respect to the op, and perhaps just offer better guidance if he's willing to learn.
If it ain't broke don't fix it Discover my world at jkirkerx.com
jkirkerx wrote:
I hear that from my car mechanic friend that works at a Porsche dealership. And my construction contractor friends as well. It is a pretty important track record to keep, as a contractor being considered for hire.
LIke I mentioned to OP also - I wonder what the team would say; if you are contractor, you really don't say that (especially, if that team is clients team).
jkirkerx wrote:
my new training says to offer respect to the op, and perhaps just offer better guidance if he's willing to learn.
No one was disrespectful to him - the repliers were really trying to understand the motives but OP could not provide real ones (except cost). Like many said, things do not add up - no one will be sure that the code will be scraped and pay you money to develop it (why would it develop it in the first place?! :crickets: ). Most likely he wanted to post something that would create a stir and increase his visibility and not a real problem he encountered (even for the Lounge).
Eusebiu
-
I am guessing you were stuck in C? I would have expected you to go with one of your generated state machines if you could use C++.
No, but generated code wouldn't have really helped me here. This flow is too irregular.
To err is human. Fortune favors the monsters.
-
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
{shrug} I've been there - it's a trade off between the time available, the memory available, and the money available. One job I worked on we often had to make some quite savage changes to the code, removing niceties, to get it to fit in the available space. Beautifully abstracted code is no use if it won't fit in the available memory. As you say, only Honey knows the exact details and trade offs, though. I'm just not sure all the opprobrium is deserved.
-
jkirkerx wrote:
I hear that from my car mechanic friend that works at a Porsche dealership. And my construction contractor friends as well. It is a pretty important track record to keep, as a contractor being considered for hire.
LIke I mentioned to OP also - I wonder what the team would say; if you are contractor, you really don't say that (especially, if that team is clients team).
jkirkerx wrote:
my new training says to offer respect to the op, and perhaps just offer better guidance if he's willing to learn.
No one was disrespectful to him - the repliers were really trying to understand the motives but OP could not provide real ones (except cost). Like many said, things do not add up - no one will be sure that the code will be scraped and pay you money to develop it (why would it develop it in the first place?! :crickets: ). Most likely he wanted to post something that would create a stir and increase his visibility and not a real problem he encountered (even for the Lounge).
Eusebiu
Touche ... That was well evaluated, for I didn't have time to read all the post and follow it as close as you did. But I like your points. The shear number of responses shows that it was a thought provoking post that questioned are own personal values or morality.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
{shrug} I've been there - it's a trade off between the time available, the memory available, and the money available. One job I worked on we often had to make some quite savage changes to the code, removing niceties, to get it to fit in the available space. Beautifully abstracted code is no use if it won't fit in the available memory. As you say, only Honey knows the exact details and trade offs, though. I'm just not sure all the opprobrium is deserved.
Alister Morton wrote:
a trade off between the time available, the memory available, and the money available
Indeed, but in this case these were not the constraints as he always wanted the cheapest solution.
Alister Morton wrote:
abstracted code is no use if it won't fit in the available memory
Indeed, that's why I told him that it would have been a more interesting question one on what's blocking him on whatever problem/solution he has, and he answered that it was only the cost (i.e. cheaper spaghetti vs. a little more expensive clean code) which is (to some extent) understandable. The thing I didn't understand is why he kept doing it (since he developed most or all of it) for which he said that it will be (probably again!!!) scrapped but he wouldn't do it if he worked for an enterprise (???). This raises other questions but after a while I gave up as the answers always got back to cost.. so, apparently quick & dirty works if you can tell the future (I never developed that capability!)... :)
Eusebiu
-
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.
-
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
-
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.
-
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?". :laugh: 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 :laugh: ). :)
Eusebiu
-
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?". :laugh: 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 :laugh: ). :)
Eusebiu
You said, and this is the entire comment with no qualification. "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..." Again my point is that ALL code in midsized companies that has existed for a while will be 'badly' written due to the way that code is maintained over time. I have certainly seen code written badly from the beginning also.
Eusebiu Marcu wrote:
and for about 17 years
And I have been doing it for 40 years. From start ups with 3 people up to companies with 3,000 developers (not employees but actual developers.)