|
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
|
|
|
|
|
Eusebiu Marcu wrote: The post would be been 100x more helpful if you posted the real problem that stops you to implement it in a clean way
In this case, what stops me is it costs too much, and doesn't pay for itself. That's what stops me.
This is round two of three planned phases of hardware+software development.
Phase 1 was reusable. Guess what? The spec changed. That code? Thrown away.
Phase 2 is this phase. Delivered at 1/2 the price, more functional, ready to present to the investors.
Phase 3 is production.
Like I said, I made this decision based on what I know of the project. I stand by it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: what stops me is it costs too much
I love that you think that these decisions are yours to take! Also, since there is no real reason (beside your view of financials) of not doing refactoring (or doing it right - assuming you don't think spaghetti code is good code) like hardware constraints, did you tell your client that in order to make the code cleaner, more maintainable would cost like $500 more? Maybe he will see this as an investment!
honey the codewitch wrote: Phase 1 was reusable. Guess what? The spec changed
honey the codewitch wrote: Phase 2 is this phase. Delivered at 1/2 the price, more functional
Who can tell you that Phase 2 won't have the same fate as Phase 1?
Eusebiu
|
|
|
|
|
Eusebiu Marcu wrote: I love that you think that these decisions are yours to take!
I love that you think you can tell me how to do my job. When you're signing my checks, you can tell me what decisions I can make. Otherwise, your opinion and $7 USD will buy you a latte.
Eusebiu Marcu wrote: Who can tell you that Phase 2 won't have the same fate as Phase 1?
I expect that it will, since the product has not been finalized in design yet.
That's why it doesn't make sense to gold plate it with abstractions that will never pay off.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I love that you think you can tell me how to do my job.
That's the thing! I am not telling you to do anything; on contraire - I am trying to help you understand that the road you took might not be beneficial for you and even tried to come up with scenarios where your decision makes sense (which you proved wrong one after the other... that's life!). Honestly, it seems like you hide a lot of decisions from the client because you (think) know better! That's generally dangerous! But keep going and see where this leads you!
honey the codewitch wrote: will never pay off
In general it's... not good to say *never*!
I still wonder why you posted this, as it's not really a discussion since your answers are like "I have experience", "I know better", etc. So, seems more like a clickbait than something really useful which actually proves the general rule.
Eusebiu
|
|
|
|
|
This is the lounge. It's not a programming instruction forum. My post wasn't here to be helpful.
I was simply making an observation about coding practices and how they aren't always applicable. One you clearly don't agree with.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I don't think an honest senior developer would agree with such a coding practice - i.e. spaghetti code - except very specific situations (like legacy, minimal change, etc.) - which do not apply to your post. So, yes, we can agree that they aren't always applicable (especially when no one will use that)  .
You either looked for validation (for whatever reason) or just wanted to waste some time...
Eusebiu
|
|
|
|
|
The lounge is the proverbial water cooler. If you're posting here you're not working. Whether or not it's a "waste of time" is in the eye of the beholder.
And for the record, I wasn't hired as a senior developer. I was hired as a consultant. So a lot of those decisions you thought weren't mine to make were precisely why I was hired - to make them.
The problem with coming at something from the outside and criticizing it out of the gate is you put yourself in a position where you have to criticize a situation you don't fully understand, and that rarely ends up making one look good, in practice.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I was hired as a consultant
The client might think it hired you as a consultant, but you didn't behave like one as you took all the decisions without consulting with him... that's consulting 101.
But what do we know?! We are not consultants... 
Also, as mentioned 100 times already... I already said we don't know the full picture! But the one you're paint is looking... a bunch of spaghetti. See what I did there?! 
Eusebiu
|
|
|
|
|
You're making a lot of assumptions about what I have and haven't discussed with my client.
I mean, it's fun to write fan fiction, but I think you could find a more engaging topic to tell stories about.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I've asked you already if you discussed with the client or not... if you cannot keep up, just quit!
Eusebiu
|
|
|
|
|
I'd only have a problem with spaghetti code if there was a fairly straightforward way to simplify it (maybe with a table of state transitions) or if it would have to evolve to support a stream of new capabilities in subsequent releases.
I worked on telecom call servers for many years, where spaghetti code made it a pain to work on various products. The problem is hundreds of supplementary services that modify the behavior of basic calls. If some of their logic is inserted into the basic call code, it soon becomes spaghetti. More services were implemented every release, so you also got a bunch of developers all needing to add more spaghetti to that code.
When I was tasked with rewriting one of these products, the design eliminated the spaghetti by separating all of the services' state machines. It used static and dynamic chains of responsibility with observer capabilities, which allowed state machines to be triggered, after which they could override or reuse basic call behavior. I'd write an article about it, but I think the design is overkill for most domains. However, it would likely be very useful when developing software that supports a lot of bidding conventions for contract bridge.
|
|
|
|
|
I'm almost doing that, but I actually have several state machines working in tandem, which, while kind of unfortunate due to the spinning plates factor, was very expedient.
The codebase is small, and a rewrite wouldn't be terribly expensive given how little time it took me to write it in the first place.
I've found with a lot of embedded stuff it's like that. You *have* to keep it small and efficient, so the rules and priorities change a bit as the landscape shifts.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I can make the argument that spaghetti code is the better solution in this case. Creating a general-purpose framework tends to hide the logic. At least when you came back at some future time you only have to understand the spaghetti, and not a framework as well. I think YAGNI and KISS both apply here.
Obviously the answer is different if you're tailoring the spaghetti for multiple solutions.
Software Zen: delete this;
|
|
|
|
|
To me spaghetti code is basically like a messy room you don't clean up. Doesn't mean you need to make a framework, but ya know... at least make the bed.
Jeremy Falcon
|
|
|
|
|
Agreed, but there's a smell when you've got a lot of seemingly arbitrary conditionals and special case handling.
I was assuming that the 'spaghetti' code described by codewitch was what you had left after you'd done cleanup and refactoring.
Software Zen: delete this;
|
|
|
|
|
I don’t remember who said that engineering is the art of knowing when one approximately equal with two and when one is much smaller than two.
Intelligent compromise is at the heart of what we (hopefully) do.
Mircea
|
|
|
|
|
As one guy who was frequent in this fine establishment used to say: "Who needs an OOP when there are copy and paste."
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
My experience is that spaghetti code is usually, but not always, the result of improper factoring with decision making conditionals either too high a level or too low a level. However, this isn't always the case and it appears Honey found one of the exceptions.
Just document the sauce out of it and sprinkle in a little garlic.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
