|
Spagetti code (in my day) usually only meant the use of GOTO (which has been declared a cardinal sin since the 1970's).
Heck I didn't know C had a goto until after 10 years of using it (c. 2003)
But if you're coding in assembler, I think there's no way you can avoid it (I mean some fools use interrupts all the time, even some compilers, but that wastes a ton of clock cycles).
BASIC, on the other hand, I have not touched since 1997 (Thank god too, I never could find a free Basic compiler then, Qbasic is crap)
|
|
|
|
|
This is C++, and the reason for the spaghetti was maintainability wasn't as a big a concern.
Also, despite being spaghetti, it actually follows the flow diagram I was given pretty directly, albeit with some necessary quirks. In that regard, it's actually got fair documentation for what it is.
But I'm not talking about gotos, but rather, for example, branching all over one C++ source file in response to various incoming events or state changes.
It's something of a Rube Goldberg contraption, in that one thing causes another thing, causes another thing in some scenarios in the code, and that can get confusing.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I just looked at some code I wrote in 2009-ish because we had to enhance it. I don't think it technically is spaghetti code, but it twists and turns on itself enough to act like it. Here's the basic environment:
* SQL & a binary file store values used in the calculations
* COBOL does the calculations
* Delphi is the middleman
* C# is the UI
But wait, the COBOL can't access the SQL to get those values, so the C# gets them and does all the same calculations as the COBOL, then passes just a few values to the Delphi.
The Delphi combines everything via a client data set, then passes it back up to the C# one value at a time. Sometimes it passes values to the COBOL as well.
COM is used 3 different ways during this process.
Oh, and the same value frequently has different names in the 3 program languages, and some of the names are the same for different values. For example, SomeAmount in C# => SomeOtherAmount in Delphi, but SomeAmount in Delphi => ThisAmount in C#.
It's a head-turner and headache-creator for sure.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Yikes! I hate doing interop between different platforms and languages.
I end up having to a lot because of the embedded work I do, and it's no fun.
I've gotten clever about it and added some tools to my toolbelt for covering common scenarios, but even accounting for byte ordering, calling convention differences, and language variations, there's also the transport layer itself and some interop - like over bluetooth comms - is like pulling teeth.
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
|
|
|
|
|
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
|
|
|
|
|
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? 
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.
|
|
|
|
|
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...
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.
|
|
|
|
|
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!).
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!
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.
|
|
|
|
|
|
And BTW, I wonder if your team members would say that you are real professional or condescending (if they find out) that, in our opinion, you are the ONLY one that delivers on time and on budget.
So, I would refrain myself from these expressions when I would embody them...
If you cannot take a joke, it's your problem, not mine! 
Eusebiu
|
|
|
|
|
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 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)!
Eusebiu
|
|
|
|
|
This job came as a small upgrade, to develop a pricing curve during construction, or a nuisance markup each time the customer changed their mind, that I quoted for $2500 USD. But they expressed interest in upgrading the application, and asked how much I think it would cost, so I thought about for about 3 minutes and said $250K USD and that's on the cheap, take it to a real code shop with lots of programmers in a shiny glass building and your looking at $750K to a $1M. In fact, I'm not even sure if a real shop would accept this project, they would probably laugh at it.
During this small project, their original code kept crashing their web server, so they outsourced the web server to a company, that laughed at the code, said it was dangerous, and placed this web server in a dark corner and isolated it off their main network. Then told them if they don't upgrade the app, they will kick it out.
I wasn't looking to make a sale from this, because I already make money doing other things, but I felt sorry for them, as this was their main app, and they can't do construction without it. And because I was a construction contractor for over 15 years, I understood construction, so we agreed on the deal.
As I got to the end, I started running the numbers, and discovered that they were lied to, and that the app didn't calculate like the original programmers said it did, and they were losing money on jobs, and didn't need the original job I was hired to do. So I'm now in the process of drilling down on the math for every item, and providing generated proof files. 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.
So back to my thought on the original post here, which has now changed ... Or is it now a question ...
Was the ops decision based on code and best practices, or was it a decision based on best business practice, and did the op look at the macro level of the project as a whole, in terms of how much revenue or cash this component can generate for investors and share holders. Or did the op look at this at the micro level, of just being a component that can bring in some personal revenue, and maybe a little bit more down the road. This is where rogue programmers need to learn some more skills in addition to software engineering.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
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? 
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
|
|
|
|
|
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
|
|
|
|
|
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)  .
|
|
|
|
|
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[^] ...
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
