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?". :laugh: 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 :laugh: ). :)

Eusebiu

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

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

jkirkerx wrote:

I hear that from my car mechanic friend that works at a Porsche dealership. And my construction contractor friends as well. It is a pretty important track record to keep, as a contractor being considered for hire.

LIke I mentioned to OP also - I wonder what the team would say; if you are contractor, you really don't say that (especially, if that team is clients team).

jkirkerx wrote:

my new training says to offer respect to the op, and perhaps just offer better guidance if he's willing to learn.

No one was disrespectful to him - the repliers were really trying to understand the motives but OP could not provide real ones (except cost). Like many said, things do not add up - no one will be sure that the code will be scraped and pay you money to develop it (why would it develop it in the first place?! :crickets: ). Most likely he wanted to post something that would create a stir and increase his visibility and not a real problem he encountered (even for the Lounge).

Eusebiu

jkirkerx wrote:

The way I see it, if your selling $18M of construction jobs a year, $250K+ is a small price to pay to confirm your not losing money.

As always, depends. If they would have seen it as you did, then yes! If they still trust the old guys, then... no! :)

jkirkerx wrote:

Was the ops decision based on code and best practices, or was it a decision based on best business practice

After a long discussion the ONLY (like the only one and no other, especially technical - don't know why he mentioned embedded... I guess to build some sort of aura over it) argument OP came up with was financials with a little bit of narcisism (I am the only one that delivers on time/on budget, I know better the project etc.; ofc, there are other points of discussions since he said he coded from the beginning which raises other questions but will ignore those), thinking that whatever he build now will be scraped in the future (because phase 1 was scrapped) and redone correctly when the real money comes in. At a high level, it makes sense if you are sure of that outcome though why would someone pay you once to write some bad code (that works nevertheless) and then pay you again to write the good code? I can understand that phase 1 might have changed so much... but also phase 2? :wtf:

Eusebiu

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

:laugh: :laugh: :laugh: Your words, dude, your words! I just pointed them out... You are too sensitive for a consultant! The same with that remark earlier from the other guy that pointed out that some think they are senior but really are not...

Eusebiu

I've asked you already if you discussed with the client or not... if you cannot keep up, just quit! :laugh:

Eusebiu

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!). :laugh: 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! :laugh:

Eusebiu

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... :wtf: 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?! :laugh:

Eusebiu

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... :laugh:

Eusebiu

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) :doh: . You either looked for validation (for whatever reason) or just wanted to waste some time... :)

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 :laugh: 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)! :laugh:

Eusebiu

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? :laugh:

Eusebiu

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

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

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

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

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

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