|
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.
|
|
|
|
|
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.
|
|
|
|
|
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?". 
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 ).
Eusebiu
modified 22-May-23 4:47am.
|
|
|
|
|
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.)
|
|
|
|
|
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
modified 18-May-23 12:41pm.
|
|
|
|
|
{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
|
|
|
|
|
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
|
|
|
|
|
|
Spaghetti code lacks an easily understandable flow to it. It jumps around in less than obvious ways, basically.
To err is human. Fortune favors the monsters.
|
|
|
|
|
This spaghetti code topic sure stirred the pot, but it's a very worthy topic for all programmers, especially the new ones. Thanx.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Something I overlooked yesterday is that you have a detailed spec in the form of these "flow diagrams". It's great when it's easy to see how code implements the spec. If that means spaghetti, so be it. Any blame then lies with the spec writer. 
|
|
|
|
|
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
|
|
|
|
|
The worst type of spec is one that fails to address all scenarios that are important to a product's behavior. The developer must then ask the spec writer for clarification or decide what to do in such cases. If the flow diagrams cover all possibilities, they pass this key test. But yes, they should be simplified if possible.
Reviews really help to avoid bad specs. Just as there are code reviews, there should also be spec reviews.
|
|
|
|
|
Correct! So, we agree - it's your job to write good code (as well as you can, ofc) even if the specs are bad!
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
