|
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.
|
|
|
|
|
That was actually my precise calculus. 
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
|
|
|
|
|
It's a screen flow diagram to be specific. There are 6 boxes on the main page loosely corresponding to the screens.
There are about 11 lines connecting them in various directions.
One trick with it, is it wakes and polls a server periodically, and goes to sleep until it's woken up by a user. That adds a bit of complexity.
Another issue is that there are inactivity timeouts on each screen that drop you back to either the home screen or the sleep screen depending on where you are.
Also there are 3 buttons and they are contextual, changing function depending on the screen you're on.
Hopefully I've given you enough of the landscape that you can understand the issue. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
it seems i do not understand as it seems i do understand . a state diagram comes to mind rather than a flow diagram though perhaps they are the same as i do not know for certain . the few times i utilized a state diagram i found the logic easy to understand .
|
|
|
|
|
It is pretty much the same, just presented slightly differently. The screens are basically state transition "landings", the arrows, the transitions themselves.
I wish I could just show you the diagram but I'm not at liberty to share it. It would make things clear.
The actual logical flow isn't terrible, per se. But it folds back on itself some (due to inactivity of button presses, or otherwise navigating from screen to screen)
There is a quirk that impacts all of the startup code, and that is the startup code must run on wake or on boot, with a different "start reason" associated with it. The machine otherwise has no indication to determine whether it was woken from sleep vs. powered on. It remembers nothing.
Also, I have a watchdog timer in the code, for robustness - this is out of band, and what it does is it starts counting down, and if it reaches the end, it reboots. This is regardless of what else happens. The reason for that is to prevent a hang, not that my code hangs, but in production, who knows?
So that's a separate flow on top of everything else.
Basically what it amounts to is rather than one state machine, it's several state machines working in tandem. That's messier than what I'd like in an ideal world, but making it cleaner just wasn't going to pay for itself.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Sounds very familiar territory.
|
|
|
|
|
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!
|
|
|
|
|
"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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
