|
honey the codewitch wrote: More importantly, progress remains visible with the spaghetti approach
Of course.
Ideals should not be applied blindly. They should be followed when they provide benefit.
honey the codewitch wrote: 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
I really, really dislike the claim that abstractions make anything better when no one can provide any evidence at all that future needs of any sort will be needed. If requirements exist, or a roadmap is known or even if someone expressed a desire for a future feature then maybe consider it. But don't do it 'just in case'.
Doing so it no better than gambling on the big wheel in a casino (one of the worst odds games in play.)
It does not insure any economic future advantage but it does guarantee complexity which future programmers must then maintain (and so must be paid for.)
|
|
|
|
|
You covered something very well here that I was thinking about earlier regarding abstractions paying for themselves.
To err is human. Fortune favors the monsters.
|
|
|
|
|
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'. 
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
