[gfiorav]

This just seems like poor justification for laziness.

You need to keep a project clean. This means profound refactors when concepts for the product change. Some rules are:

- Keep it readable

- Don't over engineering

- Easy to remove

- Good tests (complete, min stubbing, interface oriented. Never refactor and change tests at the same time.

A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant. It takes effort to maintain a clean project, many will try to say "it's not worth it". That's just out of the question, it's your job, it doesn't have to be always pleasant or easy. If you don't suffer for it a bit now, someone else will in the future (maybe clients or users).

This is what I like about open source projects, it teaches maintaince discipline. In the end, you can sum up all rules into one:

- Make it easy to maintain

[koonsolo]

> A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant.

Sometimes, your new paradigm is actually something that they tried 10 years ago.

> In the end, you can sum up all rules into one: Make it easy to maintain

That is only one of the many facets of programming that you have to balance: performance, memory consumption, ... .

If you want to push your system performance to the extreme, believe me, "easy to maintain" is not going to happen. But that is the trade-off that you will have to make at that point.

Veterans know that everything is a trade-off.

Let me give you one extreme: you are writing a throw away prototype. How much time and effort are you going to spend (=waste) on making your code easy to maintain?

I'll give you my veteran answer:

- If you are in 100% control of the project, you know you will throw away the prototype, and you can throw things quickly together.

- If you have a manager, he will take 1 look at the prototype and say "Wow, it's almost complete! Don't start a new project, just add these features to your prototype and it's done.". So in that case, make the "throw away prototype" easy to maintain.

That is what veterans bring to the table: making trade-offs in specific situations. And they've been through a lot of situations.

[gfiorav]

Good points. For the record: I'm not saying all veterans are egotistical.

I think code based performance is something that is just not as big as an issue as before. In web world it's common to solve extreme performance via cache, replication, etc.

In any case, I think that in very few cases you get to a performance requirement so intense that you can't write maintainable code. We can't argue on extremes :)

[donjoe]

I experienced while writing a lot of tests, the code suddenly became - more readable - less over-engineered - replaceable - easier to maintain since it's easier to write tests for "clean code".

[manmal]

Exactly, even if you don't write tests for a component, it pays off to think about how it could be made testable. You can still choose to add tests later on.

[LyndsySimon]

I'm 33, and while I don't think I'm "at the top of my field", I have experienced quite a bit and am confident that I can both produce and identify high-quality code.

In my mind, the biggest change as I've grown in my career is that I've gone from judging code quality to judging code suitability.

For example - the application I'm working on right now, there is is a javascript file that initializes complex data tables using the jQuery DataTables plugin. It's several hundred lines of redundant code, with several functions that actually do the initialization differently depending on the classes that are applied to the table element. It is unquestionably "low quality" code, but I have no intention of attempting to refactor it. Why? Because there are customers whose UIs are dependent upon the bugs and undocumented assumptions that are baked into that code, and refactoring it would break things from their perspective. If I did that, by the time I dealt with all the bug reports and feature requests from customers, the nice clean code that I'd written would look like the code I have now. Instead, I've written a new JavaScript file to initialize data tables going forward, and all new instances use that. They are slightly visually distinct from the "old-style" versions so users know to expect the slightly different (but now consistent) behavior. I'm very resistant to adding features to the legacy code, and instead, offer to "convert" the legacy tables to the new layout one-by-one when a new feature is requested. Eventually, we may reach a point where we can retire the legacy code - but in all likelihood, that code will be there longer than I will work here. This approach of "walling off" code that has become unwieldy and difficult to modify is one of the things that I look for when determining where a developer is in their career.

> You need to keep a project clean. This means profound refactors when concepts for the product change.

If the purpose of a company were to produce the most excellent software possible, I'd agree with you, but the purpose of a company is to make a profit. If you do a "profound refactor" every time requirements significantly change you're likely to never launch a product at all, much less iterate quickly enough to build a profitable product. You have to learn to deal with cruft and manage its lifecycle, not try futilely to prevent it from ever occurring. Part of that is learning to break things down into discrete components and limit interdependencies so you can refactor each component in isolation, but another part is learning to segregate cruft that has accumulated and keep shipping without creating a mess that slows down how quickly you can iterate in the future.

> It takes effort to maintain a clean project, many will try to say "it's not worth it".

"Worth it" doesn't necessarily mean "worth it from the perspective of the developer". It can also mean "doing this right is going to take longer, and in order to meet our business goals we can't take the time". As long as the long-term impact of these decisions are passed on to the decision-makers on the business side, there are absolutely times when "it's not worth it" to write clean code.

> That's just out of the question, it's your job, it doesn't have to be always pleasant or easy.

Nope. Your job as a developer is to provide more business value than you consume. If you're getting paid $100k you must provide more than $100k of value or you will eventually be out a job, regardless of how clean your code is.