|
Self documenting code is ofcource the best. That is if it's really documenting in a fashion that anyone can understand. To achieve that means lots of time spent on clever naming.
|
|
|
|
|
If your diagrams are riddled with:
honey the codewitch wrote: so many conditions around state changes and such
then, how can you trust the accuracy of them diagramz?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Because as complicated as they are, the flows are coherent.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Interesting. If there is no maintainability argument against spaghetti, then the only argument against it is that spaghetti carries a greater risk of subtle typos. Whereas a generic machine could be "proven" to be correct with a great effort. It is not a clear bet, but I think that I too, would lean towards: pasta.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Regarding the flows, the reason they are complicated is we're dealing with 3 buttons, and on top of that, an e-paper screen with a 3 second refresh.
Buttons must ergo be contextual based on the screen, and transitions between screens must be minimized.
Furthermore, the machine sleeps. When it sleeps it runs just like a hard reset on wakeup, but with a different "wakeup reason" so you use that to determine whether you were awoken vs powered on.
There's a maintenance screen that can be gotten to by holding all 3 buttons for 10 seconds.
Finally, there are inactivity timeouts on each screen, polling intervals for the server CU, and and a watchdog timeout to make sure it doesn't hang.
So like I said, it's coherent - it's just complicated. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: 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.
Knowing why this is a bad idea separates the seniors from those who think they are seniors but are not. Even on the off chance you can make sense of spaghetti, in a year or two it'll be harder if you come back to it. If it's handed off to another dev, it'll be harder.
As an aside, if a rewrite is only $2k, then it sounds like there should be no need for a diagram at all.
But anyway, if it will be used for anything customer facing, there should be some design to the code. Otherwise, don't do it. If it's a personal script that'll never leave your own machine that's fine or maybe even for a prototype/POC. But at the end of the day, people talk about saving time with a poor design simply because they never learned proper design to begin with and time is the number one excuse people use to not do something. It doesn't take much effort to avoid spaghetti despite not having the best stellar design.
Jeremy Falcon
modified 17-May-23 7:54am.
|
|
|
|
|
Jeremy Falcon wrote: Knowing why this is a bad idea separates the seniors from those who think they are seniors but are not. Even on the off chance you can make sense of spaghetti, in a year or two it'll be harder if you come back to it. If it's handed off to another dev, it'll be harder.
Perhaps I wasn't clear in my original comment, but I tried to be explicit about the low cost of a rewrite.
There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
There's little justification for even spending $500 to again, possibly save $1000 down the road when the downside is that you go dark in terms of client visibility as you're developing the framework in the alternative.
Edit: What we have is a fundamental disagreement, which you're trying to paint as hubris, and that's insulting. I think my contributions here speak for themselves, as well as my extensive history of successful development projects. I wish you'd be a little bit more circumspect about what you write here. It would be nice to keep it civil. 
To err is human. Fortune favors the monsters.
modified 17-May-23 8:35am.
|
|
|
|
|
honey the codewitch wrote: There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
Despite needing a diagram? Something isn't adding up. Not sure how many people you've employed before but $500-$1K is a joke. Seems that the diagram would take longer than the code according to you. Which makes no sense. People don't diagram something that takes 1-2 days to develop.
honey the codewitch wrote: I wish you'd be a little bit more circumspect about what you write here. It would be nice to keep it civil.
I'm not being uncivil. I'm just challenging you. If saying a senior programmer knows why this is a bad idea is being uncivil in your book, then that's just oversensitivity.
I could also say that always arguing with people (this is where you say you're not) is also being uncivil. But, this is the Internet. Arguing is a way of life here. This is where you say you're just defending your position. And so am I. But, don't make it seem like I'm a bad guy here because I speak of what a senior should know.
But don't worry, this is easily solvable. I'll just stop replying to your click baits.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Despite needing a diagram?
I already have a diagram, which I made the code closely follow.
Jeremy Falcon wrote: Not sure how many people you've employed before but $500-$1K is a joke.
You've maybe never done embedded? Projects don't sprawl when you have kilobytes of RAM and less than 1MB to store your code.
Jeremy Falcon wrote: I'm just challenging you.
I'm sorry but that's false. If you were just challenging me you wouldn't be insinuating things like I think I'm a senior developer when I'm not - that's insulting, and it's nonsense. You should know better.
Jeremy Falcon wrote: I could also say that always arguing with people (this is where you say you're not) is also being uncivil.
There's nothing uncivil about a debate. This is about the statements you made that specifically did not further it.
I stand by what I wrote.
To err is human. Fortune favors the monsters.
|
|
|
|
|
You're missing the point. Thus, this is going nowhere nor will it. It's just another pointless argument. I'm gonna go live my life now.
Jeremy Falcon
|
|
|
|
|
Solid plan.
To err is human. Fortune favors the monsters.
|
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Jeremy Falcon wrote: what a senior should know
In general, you are right!
He is just arguing that in his very particular case it's better to break the rules (and by better he means time to deliver and money saved, not technical excellence or performance improvements). Unfortunately, he did not paint the entire picture - only the parts that supported his decision.
Who knows?! Maybe in his very particular case the decision was correct.
Eusebiu
|
|
|
|
|
Sorry buddy, but I disagree. There are different levels of good design and for a one- or two-day job, you are 100% correct in the fact we don't have to go full on SOLID, RAII, etc. But that doesn't mean you don't do the basics of a decent structure that should be ingrained in our subconscious by now - especially if it's for work or pay. No senior should and I'd never hire one twice that thought otherwise.
Also, there are factors that don't add up. If this quick project was so insignificant, there shouldn't have been a diagram in the first place. Nobody in the industry diagrams anything for a one-day job - nobody.
And lastly, if you check out the entire post, you'll notice my points where entirely skipped over too. This whole thread was just clickbait over someone being bored.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: If this quick project was so insignificant, there shouldn't have been a diagram in the first place.
Indeed! The thing is that we don't know the full picture - maybe some PO/BA really wanted to have that flow diagram which got complex over time (no one said it was created at the same time with this 'small' change).
If the project was already a spaghetti code and the change was minimal (one can debate what minimal is, but since a full rewrite would be 2-3 MD ~$1-2k, I would assume just some functions), then it really doesn't make sense to refactor the whole thing (as small as would be) just for that minimal change. It makes sense if new changes/requirements would come but apparently that's not the case. If the client is fine (assuming that one asks it) with the spaghetti code and nothing will be added in the future, then again, doesn't make sense... E.g. think of a security patch/blocker that is dirty, does the job and can be released in 1h - this scenario I completely understand (I would recommend refactoring but if the client doesn't have the budget - which contradicts the 1k-2k rewrite but anyway...  - then it's on the client).
If OP was part of the original team or at least was asked to change something previously and did not inform the client on the structure, then it's on OP.
Eusebiu
|
|
|
|
|
That's a ton of assumptions, but I can promise you that nobody wants to flowchart anything insignificant. And no client will be ok with spaghetti or crap code. Try asking one...
Jeremy Falcon
|
|
|
|
|
Indeed! My question exactly to the OP... he didn't bother to answer it because the answer is obvious!
I guess the client had some bad luck with some previous devs and now he trusts him completely since he's delivering an end result to some expectations, not knowing what's underneath mainly because it thinks/hopes that whatever comes next doesn't need whatever OP is delivering... which is kind of stupid but who knows...
LE: and you know what will happen? After the investors will give them some money, the client will not agree a refactoring/recoding (because it works! why should we rewrite it?!) and OP will either quit or work on his free time... )
Eusebiu
modified 18-May-23 14:41pm.
|
|
|
|
|
I don't think you're hearing me man. The story doesn't add up. The answer is obvious, but not in the way you're suggesting. None of this has to do with working in free time to make up for anything. I'm stating that even if the project isn't not important, there's a level of competency we should live up to. Why we're getting away from this point, I don't know.
Jeremy Falcon
|
|
|
|
|
honey the codewitch wrote: There is no justification for spending $1000 to possibly save $1000 down the road. It makes no sense.
This is not your decision to take; it's the clients/management/call it what you want. You cannot possibly know what's down the road.
Ofc, we don't know your contributions - you might be a 10x developer! You don't need to feel insulted if someone says your decision is not of a senior developer - everyone makes mistakes and no one is always right!
The thing is that some of the arguments are not adding up... I just wonder why you posted this knowing (because you 'ducked') that this is not common/best practice. Are you looking for validation? (you will probably find it from junior developers or some devs that know your project).
Eusebiu
|
|
|
|
|
Yeah, no it's my decision.
The client gets deliverables, and projects designed to spec. I get to decide how to get there in the least expensive way possible, that delivers something robust and to spec.
I am not a fan of micromanagement. I work for myself.
And yes, I do know the cost of a rewrite, because I wrote the code.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: client gets deliverables, and projects designed to spec. I get to decide how to get there in the least expensive way possible,
Ok but that doesn't mean that is the best decision for the client. The client might pay more to make it cleaner.
honey the codewitch wrote: And yes, I do know the cost of a rewrite, because I wrote the code.
So, as a senior you were fine with writing a spaghetti code from the beginning... Sorry, but that doesn't look like a good decision of a senior... Oh, if you started when you had 1-2y of experience and after 20y you got on the project again, then ok... I can understand that.
Eusebiu
|
|
|
|
|
The client is on accelerated timeline, and this isn't the final round of development. 5 years from now the software will be completely different, as will the hardware.
As a senior dev I'm fine with making any decision that leads to delivering a product on time, that works as specified, and provides the best value.
This provides the client value in a way that the abstracted code would not.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I'm fine with making any decision that leads to delivering a product on time, that works as specified, and provides the best value
Again, that's not your decision. YOU don't define the value, the client does. You can make any decisions technically that will deliver the product on time, but that doesn't mean it's the best one for that client - it might me at the current time, but this remains to be seen.
Since we don't know the details for the project and your client assumptions, we can only rely on our previous experience which tells us spaghetti code is bad!
Eusebiu
|
|
|
|
|
This client is happier with me than he has been with any developers on his previous projects, teams or otherwise, I'm his MVP - according to him.
So, when I have to weigh that against your assessment I come away thinking I'm doing this the right way.
My client is thrilled with my work. That speaks for itself.
If I was working on a software team, or if I was working with a codebase that was more than a couple of pages long, I would approach it differently.
I approach it the way I do based on experience doing embedded, based on my knowledge of this project, and based on the clients expectations and desires.
And of all the people on the engineering end of things, I'm the one that has delivered every single time on this project. Nobody else can say that on my team.
That also speaks for itself.
That's concrete. You're talking principles. That's abstract, and they sometimes don't survive contact with the real world.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: My client is thrilled with my work. That speaks for itself.
That is 99% sure because you focus on financials and time to deliver.
honey the codewitch wrote: based on the clients expectations and desires.
Most likely the client isn't aware what happens if you quit tomorrow. If you would tell them that the code is spaghetti (as you pointed out, not a 3rd party review) they wouldn't be that thrilled, especially if you're their MVP (this means future work) - except, yes, if they decide to scrap the whole thing and start fresh (which can happen though seems a waste).
honey the codewitch wrote: You're talking principles. That's abstract, and they don't survive contact with the real world.
Depends on how you define real world: in my real world I also work for myself and I don't write spaghetti code and also my clients are happy with the code (sometimes with many abstractions) I write.
If you say embedded code is mostly spaghetti code because of this and that (like hardware constraints etc.) I am sure that there will be someone out there to tell/show you otherwise.
The post would be been 100x more helpful if you posted the real problem that stops you to implement it in a clean way then trying to search for validation (or for whatever reason you posted).
Eusebiu
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
