The Joel on Software Discussion Group (CLOSED)

Sorry, this is a rant but I feel the need to vent.  I work with .NET technologies a lot, and one thing I've noticed is that nearly no one actually cares about taking the time to properly design and write code!  I'm talking about simple things like using an n-tier architecture, or not putting all your logic in ASP.NET code-behind files.  And yet nearly every company I've worked for has done this sort of shit; just hacking together code. 

The business model of the day seems to be "Just get something working and get it to the customer so we get paid."  I mean, maybe I'm just being a primadonna about it, but shouldn't experienced developers try to write good code, not hacks that I'd expect entry-level, wet-behind-the-ears graduates to put out (until they learn better)?  Is this a .NET thing, since Microsoft seems to tout "fast" over "good" (to pick two sides of the Impossible Triad)? 

As an aside, while most of my peers here seem to think it's better to work for a company that sells software as opposed to one where software supports the internal business, I've found the most likely candidates for the "Just get it working so we can ship it" mentality are companies where software *is* the business.  It's been the case in nearly every company like that I've worked at, and it's very frustrating.  I'm wondering if its a .NET thing, and if I should seriously look at learning Java instead - Java at least has a history/community of design patterns and proper architecture (sometimes *too* proper), but I'd take that over hackjob code any day of the week.

In addition, I've found this to be a bad career move, even short-term.  By going back to the "dark age" and writing hackjob, unorganized code, you hurt your professional career because you'll be used to writing code that way if you ever get into a company that does it the right way.  And then you won't be as productive, because you're so used to hacking together shit.  It happened to me once before, and I lost my job due to having worked in the past only on hacked-up, "We don't care about developing this right, just make sure it works so we can send it to the customer" type projects.

Thoughts on this?  Have you ever just felt "tired" of the language you primarily use, due to the proliferation of shitty code that's written in it?  Am I just being stuck-up?  Maybe I'm in the wrong field, after all.

I'm in an interesting position at the moment. I'm working as a project manager/coach for a team developing a new .Net application. It has lately become apparent that I'm a better coder than most of the developers on the team, which is pretty scary considering:

1. I didn't know .Net or C# before joining the company
2. Coding hasn't been my primary duty for several years now.

I was pretty shocked. I've seen everything from inconsistent variable naming, blatant repetition of code that should have been refactored into a method, poor design, hundred line methods, etc. The worst is that all the business logic is now fully intertwined with the rest of the code. And these are all considered "senior" developers.

So, we've essentially written a legacy application. Cool.

Some of my conclusions are:

1. Most developers aren't anywhere near as good as they think they are. By most, I mean the majority.

2. It seems, these days, that a couple of years of experience with a framework (like .Net) entitles you to call yourself senior.

3. Universities and schools don't actually teach much about good coding habits. You have to learn this on the job. However, I find that many so-called "senior" developers aren't very interested in learning. In other words, it's a lot harder to mentor a "senior" developer and so the habits go unchanged.

This is the major danger of calling people senior too early.

Time is money. Any questions?

There's good news and bad news for you.

The good news: People generally want to improve. You may have to teach them, and you might have to develop diplomatic skills you never thought you'd need, but you can do it.

You're going to have to adjust your expectations a little. You can't fix this overnight. All you can do is leave the code in a little better state than you found it. Do this every day.

Get a copy of Michael Feathers book "Working effectively with Legacy Code", roll up your sleeves, and start making the code a little better each day.

The bad news is: if management doesn't understand why quality matters, it's going to be a long, hard slog.

Good luck.

"All you can do is leave the code in a little better state than you found it. Do this every day."

Ah, but here's the rube:  If I do that, and the boss asks me what I'm working on/how the project is coming, it's probably not a good idea to say "I'm cleaning up this code to make it work better".  It's just such a downer - I see the lame code, and I feel that it's going to "waste time" if I refactor it, because the boss wants me to add the new functionality, and he expects me to do it the same way the code is already written (i.e. hackjob), so if I don't and clean up the code, it looks as though I'm screwing around and not doing the task that was given to me.

You've just described almost every place I've ever worked.  Sure there are a few components that are done well, but much of it isn't.

That's what I love so much about running my own business and being in complete control.  If I need to go through and refactor something and it takes 4 hours (with no other immediate benefit than 'it feels right'), then I do it.  My code base is the very best I'm able to produce, and it's better than anything else I've ever come across.  (Well, probably not: I've seen a few impressive open source libraries). 

Get started and go it alone!

Ruby,

You've complained about every company you've worked for except the one that fired you.  Perhaps you do a horrible job evaluating companies to work for.

Besides, its much easier for people to look at the costs as a short term prospect as opposed to long term.  Structure generally helps the most in the long term.  And sometimes, that is the right decision.

Find someone there who you like.  Ask them questions about why they made their choices.  Try to learn something before you complain.

I think one of the first problems is that at least half of the programmers out there do not have computer science degrees.  Comp sci tends to give you that foundation of structure, and knowing not to use globals, etc...  If you come from an MIS or other "Visual basic" type school of programming, you are more worried about just getting something working.

The second issue is usually there is not a huge performance penalty in these days of ample memory and processor speeds.  So spending time to make code super functionalized and object oriented isn't noticeable to the end user.

And the third reason is that the frameworks make it so easy to create something in the first place that most developers, if they do have to touch someone's old code find it easier to just rewrite it in their style.

Yeah, I've seen it too.  I joined a consulting company a little over a year ago, and the quality of the code I've seen cranked out by this company is really, really dismal.

I think the problem is pervasive and extends beyond programmers to the businesses they work for.  It's not a good trend.

Quality (as in supportable in the quture) isn't an objective anymore.....people seem to reckon on not being around when v2 aurfaces.

(Cat's out of the bag, might as well drop the fake name)

You're right - I don't think I do investigate the company enough before accepting a position.  And yes, only the job I lost actually had their shit in order (and yes, I lost it due to having only done hackjob type projects - it hurt my contributions). 

How should I approach it then?  Ask to see a sample of the companys source code?  I doubt anyone would agree to that.  Anyone I talk to is usually quick to praise how great the developers are and how great the codebase is (especially if it sucks).

Come on, you don't need to see code to find out that it's a hackshop. Just ask a few questions

- how much time do you reserve your developers for refactoring?
- do your developers do code reviews?
- if you find that a deadline is not going to be met, what do you do? (
  a) postpone features
  b) postpone deadline
  c) Just do It (TM)
- what are some coding standards in your team?
- have you heard of and adhere to the DRY principle?

I could think of many more questions.

But hey, I know what you are talking about. My company is just now struggling to move away from this, though, and it's encouraging to see it (just now postponing a lot of features in a current release), but it's a long process to change that culture.

Do you talk to other developers while interviewing?  If the code is bad enough, I think they would tell you (it's fun to poke fun at the code base if you didn't write it).  Maybe

There is no conclusive method.

First, asking about process can give you insight:  a well designed development process is indicative of quality.

For example:  source control, configuration management, bug tracking, specifications, and documentation are indications of some notion of quality.  You can ask about the development process.

Having a QA department or at the very least a QA process is a sure sign that they care about quality to some extent.  Ask what their process is to catch bugs before release.

Of course, you could have hacked code that gets the job done.  Which isn't a sin:  it solves peoples problems.  Coding standards and peer reviews are two signs that the code will be more than just hacks.

You can also ask how they value quality v.s. deadlines.  Peers will be more honest in answering this question.  But it doesn't hurt to ask, it can be instructive.

Also, find out information about your soon to be coworkers when you interview.  Judge their quality yourself based on your interview of them.

Start talking to them about their experiences.  If they keep saying "we had to completely rewrite" or "it was all spaghetti", consider them red flags.

You can't always turn them down, but you can probably bond with them over those experiences ;-)

Maybe it's a function of the environment.  Business does not care about good code, they don't know what good code is, all they know is that they need Obscure Feature X and they need it YESTERDAY.  However, down the line, they will feel the results of not having an interest in their systems being built right.

The maintenance is always a nightmare on these hacked-together spaghetti-code systems... but there is yet another market for programmers to capitalize on.  I personally wouldn't want to, and none of my peers would.  But, there are plenty of unscrupulous coders out there who could care less about what they are maintaining as long as it's a cash cow.

Come to think of it, the only coders that don't mind maintaining a nightmare system are the ones that write them in the first place... so I guess it's just job security.

Writing excellent code that is easy to test, change, and reuse means you actually *finish* things and spend less time building systems.  That doesn't fly in a market where most programmers are contract employees paid ridiculous hourly amounts.  The average Blub programmer has a vested interest in dragging everything out as much as possible because they get paid as long as Generic Business System Z is in development.

And for the record, YES, people care about writing good code.

For an example, look at some of the better open source systems out there, and (for fun) Apple's Cocoa Library.

Businesses (Customers) want their problems solved at the lowest cost to them, but certainally less than the value they place on having the problem solved.  They aren't interested in the details of the solution, only the cost and schedule.

Investing in infrastructure is like any investment.  It has potential future value, risk, and cost.  Balancing these factors does not always lead one to the decision to invest in the future because its not expected to recoup the investment.  For every system that needs constant maintenance, there are 10 systems used for decades without needing a single change. 

Of course, some infrastructure reduces cost and risk.  The key to a professional is to be able to determine when to invest and when to spend.  Too much of either leads to disaster.

If you don't have time to do it right in the first place, how are you going to have time to fix it later?

Code should be just structured enough so that it's maintainable and not brittle. Too much structure has the same problems as too little structure.

Seconding the Feathers book recommendation.

I took a job last year and was *horrified* at the code quality I discovered.  I never would have suspected how utterly shit it was going to be in talking to the dev team manager and the tech lead.  It turned out to be one of those situations where it was built sloppily by very green programmers a long time ago, and then milked like a cash cow for six or seven years with a management (several layers up) attitude of "it makes money, why fix it".  It was a grueling thing to try to deal with, so much so that I began to doubt my own competence and abilities because working with it every day was so hard (by that I mean the codebase was so rotten even comparatively trivial features would take weeks to work in and bugfix) and so depressing.  Eventually, well... I just quit and got a better job (the short version was that I contracted at night for a different place and when they said "hey, come on board full time to help us push out some big projects" they didn't have to twist my arm much). 

Not much point to this reply I guess except to say that I've been there too and things can be better.  (But you may have to jump jobs and/or move to find them, such is life.)  Of course, coupled with this is the fact that perfection does not exist (I imagine even google has code somewhere that makes the people who touch it grumpy, even with virtually unlimited funding and time and staff competence), so the best you can hope for is a humble quest for self-improvement and continuous organizational improvement. 

@Phil, unfortunately having a CS degree seems to be largely orthogonal to produced code quality IME.  At best it is a very weak indicator.  Some of the cleanest code I've seen written was by a linguistics drop-out, and some of the worst by a guy with an MSCS (let's just say that the nickname he earned in that group was "trainwreck").  It certainly makes a good programmer better to have that exposure, but I don't think it makes a programmer a good programmer (by itself).

"I think one of the first problems is that at least half of the programmers out there do not have computer science degrees.  Comp sci tends to give you that foundation of structure, and knowing not to use globals, etc...  If you come from an MIS or other "Visual basic" type school of programming, you are more worried about just getting something working."

So I guess that even though I hate my data structures/algorithms class, I should be glad that I'm at least having to learn how to do things the *right* way and I'll be a better programmer for it?  That does make me feel better (even though I didn't do a CS undergrad degree).

> @Phil, unfortunately having a CS degree seems to be largely
> orthogonal

ditto that. I work with 2 compSci and they obfuscate and bloat everything. They do better than some of the those with no compsci degree but the best guy has a Math degree.

I think a code review is essential. I think if I were to go to a new place that would be one question I'd ask, how often and how do you perform code reviews? I've never participated other than informally with the Math guy I mentioned above.

Luckily some managers who thought they could code have left. One compsci guy stopped working as a cowboy and is now an analyst and some other people have left and my new managers says it's cool to spend the time on code reviews.  I'll see how it goes.

BTW, about quality of coders. We were looking for some new developers and it was hard, very hard.

The business model of the day seems to be "Just get something working and get it to the customer so we get paid." 

I'd venture to say that this is not just the model 'of the day' -- it's been the model ever since the Eniac :)

That being said, the mediocrity found in our industry is not unique. Mediocrity and "quick solutions", coupled with abismal customer service is what's "hot" now in our society. It permeates every aspect, not just software engineering. It is rewarded and sought-out, when not simply outsourced so...take heart :)

Regards code reviews, probably the best system I've seen for handling it was at a place that used a "sub-ticket" capable issue tracker (a hacked-on JIRA install, in their case).  Basically the team lead would create a child ticket of the original defect/enhancement ticket that represented the code review, which would be assigned to the reviewer.  You'd mark it done when you finished the review (or you'd kick it back and forth with the original author if changes were needed), which would open up the workflow for the master/parent ticket to progress onwards to QA.  This is a really wordy description of something that in practice was quite fluid.  Particularly critical tickets would get two separate code reviews.  What I liked about it was that it integrated into the rest of your workload management nicely so it was harder for people to "get around to it" (i.e. not do it, forget, etc.) and easier for the team lead to load balance work appropriately, all without being unduly complicated or formal.  We radically reduced our defect count by doing this (both bugs that made it to QA in the first place and bugs that slipped past QA to the customers, with most of the stupid simple stuff caught by us the QA folks could concentrate on flushing out the really gnarly bastards).

Just to take this discussion in a bizarre direction:

Is it possible that the tools and the products and how they are sold to industry are the problem? Particularly Visual Studio?

The attitude in programming today seems to be that the platform and the IDE and the libraries and the language are absolutely everything, and the programming itself is just some inconsequential and fungible "bit" part.

A few years ago, before commercial libraries and tools were so comprehensive, programming skill was "naked" and on display for all to see, good or bad. A lousy programmer had no where to hide.

Reach farther back in time to the 1980s when developers had only tools like C, and add on libraries to supplement the language, and it was really pretty much impossible to get anything done unless you *really* knew what you were doing. The only people I knew who developed demonstrable, complete shrinkwrap applications had balls of brass.

Now, it's "training wheels" on everything and with CLR type languages it's impossible to crash the machine.

The complexity and depth of developer's tools today is so extensive that it's very difficult for most developers to focus on any "craft" aspect. So programming has become in many quarters a Lego assembly exercise, even when it shouldn't be.

My $0.02.

"The complexity and depth of developer's tools today is so extensive that it's very difficult for most developers to focus on any "craft" aspect. So programming has become in many quarters a Lego assembly exercise, even when it shouldn't be."

I think that goes back to the point that simply knowing a framework doesn't make you a senior developer.

Ever notice how nobody ever advertises for a "good, solid developer who knows enough to write clean code in any language they work with"? Instead, we look for people with 2 years of .Net experience.

Clearly, learning how to write clean code that's easy to maintain, easy to test, easy to understand is more difficult than learning .Net, but you'd never know it by looking at job postings.

This is what drives me crazy when I see developers posting about "What kewl new framework/language should I learn".

Almost all the existing code I have worked on was like opening a big can of "OMFG WTF IS THIS??" Redundant functions, code in case insensitive languages to whatever the CAPSLOCK key happened to be toggled to at the moment, zero comments, sixteen page subroutines, code copy-pasted from subroutines creating duplicate code, miles and miles of dead code, etc... *shudders* All in the name of 'getting this damn thing to work'.

A few systems have been well structured pleasures to work with, but this has really been the exception rather than the rule.

One other comment:

A lot of developers I've worked with seem to want to build a reputation as being "fast". It's gotten to the point now where if someone tells me some developer is fast, I immediately file them in the "to be watched carefully" category. I'm right often enough to make that the best default behavior.

Guys: slow down and learn to defend the code. Yes, there are managers out there that don't care about quality and will try to squeeze you. You don't have to help them by giving them low ball estimates. Refactoring and code maintenance are part of the task, not bolt on afterthoughts. You have to be sensible about how much refactoring you do, but at least give yourself some time to clean a few things up.

Don't even talk about refactoring and cleaning up code in front of managers that don't understand what you're doing. Just keep it simple.

"The business model of the day seems to be "Just get something working and get it to the customer so we get paid.""

There's an old saying that goes like so:

I can offer you:

1.  Fast
2.  Cheap
3.  Quality

product.  Pick any two.

If everyone had 20/20 vision, this thread would never exist.

It is really hard to define "good code". For example:

> I'm talking about simple things like using an n-tier architecture, or not putting all your logic in ASP.NET code-behind files. 

I really hate it when people don't but the logic in the code-behind files. That's what it is there for. If you need to share the logic, you move it to a the code-behind file of a control.

Right now I'm wading through a 2000 line mega-file. It is like someone ripped the guts out of about 2 dozen pages and dumped them in one steaming pile of gore.

But that's just me. Other people have a totally different perspective.

If you were working on your own, as in running your own business, what would you do?

If the things you want other people to do at your current job wouldn't make you a winner over your competition in this hypothetical case, then it really isn't worth that much--is it?

In other words, take this from the context of your abstract belief about 'good code' and pull it down into practical reality. You'll understand that true and useful improvements are actually fairly rare even with great development processes--you'll have more patience to grow slow.

>> I think that goes back to the point that simply knowing a framework doesn't make you a senior developer.

Re: emphasis on platforms, frameworks and other commercial "plumbing" ---

My point was somewhat subtler. My belief is that most programmers' personal "bandwidth" - IE, ability - is too narrow to do all of the following competently and also concurrently:

- Make the boss happy with "obvious" achievements that appear to further the business
- Become highly proficient with current programming frameworks
- Develop code that is clean, easy to understand, etc etc
- Maintain and extend old stuff with similar attributes
- Keep up with new product developments that prevailing practice in this industry pretty much mandate that "everyone" must regularly accomodate.

You generally can't get a job today by claiming that, nor even demonstrating that, you are a solid developer alone. You also have to demonstrate your name-brand buzzword compliance with recent tools.

And great point about "fast" as a goal.

I get the impression, that a lot of developers today, especially younger ones, are trying to appear "fast", while groping in the dark to apply programming tools that they hardly understand.

I think that's the norm today: most programmers using stuff that they hardly understand and which itself is changing underneath them.

Bottom line - most corporate programming seems to have become a distracting pain in the ass, with sort of the worst characteristics of assembly line work and slavish use of mandated tools put together.

> - Make the boss happy with "obvious" achievements that appear to further the business
Bosses want 2 things:
1. A plan
2. Progress on that plan.

Give them both.  Straight hacking on code doesn't give them #1, and gives a very poor #2.

Ultimately it depends on the boss.  If they're non-software twits, then add GUI stuff slowly.  Specifically, put in a shell proto and fill it in with real stuff slowly, while simultaneously adding (proto shell or real) additional UI bits.

If the boss is worth anything, show them a UML diagram and show them how you're working through it.


> - Become highly proficient with current programming frameworks

Simple: if something isn't easy in the framework, figure out why not.  If the answer is "because I'm doing it wrong" then do it right.  If the answer is "because a fool wrote the framework," then you've mastered the framework.  Make the smallest hack possible to get it back on track, document the crap out of that hack, and go on with your business

> - Develop code that is clean, easy to understand, etc etc

Remember that the reason we're taught to write code 'properly:' well structured, documented, maintainable, is for the sole purpose of making the software development process *easier*

That's day-to-day discipline.  Think of it as running a marathon vs sprinting.  The marathon runner can hold a conversation while running.

> - Maintain and extend old stuff with similar attributes
If it's clean & easy to understand, this isn't too bad.

> - Keep up with new product developments that prevailing practice in this industry pretty much mandate that "everyone" must regularly accomodate.

When the fools who wrote the library fix it, you'll be excited, and will pick it up out of pure need.  Other than that, keeping up with 'prevailing practice' (as industry really means it), is what, 1 new book every 3 months?  And most of it is fluffy b.s. that's pretty useless in real life.

C'mon, how many different re-applications of MVC do we really need to know?  Just skim the overview page and the dev docs and it'll be straightforward enough to know what the newest API of the block is.

Really, CS doesn't really change too fast.  Big changes come what, every 5 years?

But does it blend?

> The business model of the day seems to be "Just get
> something working and get it to the customer so we get
> paid."

Yup.

> shouldn't experienced developers try to write good code

Yup.

That's why there have been dozens of threads in this forum about the way businesses discriminate against experienced developers.  If you want to see really talented developers, visit your local unemployment office.  (Of course there are a few exceptions.)

I just started working at a place, where the code is the most horrible I've ever seen in my life. They didn't even get the most basic things right, for example consistent naming of table columns or using "not null" columns. I'm not kidding.
On top of that sits a multithreaded .NET application, where it is obvious that the developer had never worked with multithreading before and didn't care to read about it before implementing it.

While working on such an application does suck, I'm actually glad that software like this exists out there. It gives those who care about qualitiy a nice headstart when they start their own company.

I can speak as an ASP.Net developer because I used to be one. IMO there are a couple things that contribute to the problem of people putting their code all in one place. First off, most people think linearly and procedurally about programming. I spoke with a friend recently and he made an off-the-cuff remark that "87% of programmers don't understand OOP". I'd say this is true. I worked with MFC from 2000-2001, and then ASP.Net from 2004-2006. Almost every project I worked on was code somebody else had written, and all but one of those projects didn't use proper OOD. In the one case where good OOD was used some of the members of the team had gotten trained in Java, and ultimately left for jobs using it.

The second contributing factor is an overuse of development tools. It's very easy when using VS to just let the tool design your app. for you, in which case all database connections will be instantiated on each screen or page, and all logic for each screen will be in one place.

Even when I worked in MFC, most of the projects I worked on had 98% of the code in the views, even though it offered a document-view architecture. It seemed as though most developers ignored it, and they put hardly any of the code they wrote into business objects, despite the fact we were working in C++. Everyone worked as though they were writing procedural C programs. Nice and linear.

Not to say everything is "greener" in Java-land. Several years ago I remember talking with a friend who told me he was shocked at how badly the Java code he was working on was written. He said it looked like it had been written by C programmers. All the code was written into one big object with the methods used as procedure calls.

I plead guilty to having written some bad ASP.Net code. I was new to the web platform, so I wasn't sure how OOP was supposed to work in it. I let VS.Net dictate the design of my app. In the first project I worked on I created a disaster. It worked, but architecturally it was an embarrassment. Part of it was I was under a severe schedule crunch so I didn't have time to do it well. Some time later I had the opportunity to work on something similar and I did it much better using a good OO design, mainly by avoiding VS's wizards and design tools as much as possible. This was in .Net 1.1. I even found a way to databind to my business objects. It was SO much better!

Nowadays I'm studying Smalltalk and good OOD.

One other thing. With rare exceptions, every project I've worked on has focused on keeping up front costs low. My career up to this point has been in writing custom business applications. There is very little thought given to good engineering, or long-term planning. Really, the focus coming from management has been on creating a souped up prototype, for as little money as possible, but selling it as though it's a finished product. That's what it really comes down to. This was true when I worked on both Unix and Windows projects. The platform and the language didn't matter, though in the Unix world there tended to be more pushback from the development manager to upper management to allow us the time to design stuff well.

It's been my experience that the customers think software is "magic" anyway, and they can't tell the difference between a piece of software that's well designed and one that isn't. Their barometer of whether a program is written well is if it crashes or not. This is one accurate indicator, but by no means is it totally accurate. It could be a total mess under the covers yet still run well. It's just that maintaining it is going to be a problematic, costly bitch. I've tried to go against this grain and actually design software well, and while I've managed to succeed in some isolated incidents, it's an uphill battle precisely because customers can't tell the difference. To them a badly designed system that works, and appears to be cheaper to produce (up front) is cheaper, and therefore better, than a well designed (and more expensive up front) equivalent.

So therefore it's just easier to create a mess. It satisfies the up front cost measurement that most custom projects are based on. By the time the maintenance cycle comes around it's only the poor developers who have to work on it that notice. I've never seen the customer notice this. The cost profile of the maintenance work, and the glitches that come with it, probably fit within expected norms, because most software projects are like this.

A part of the problem is lowered expectations. If whoever was managing the customer end of the project would actually understand what creating software is about and demanded to do code reviews, then you'd see quality go up immediately.

That's familiar.  I said about this problem of "senior developers" a while ago: http://www.buunguyen.net/blog/the-wrong-attitude-of-learning-on-the-job.html.

They probably cared as much as you did when writing your horrendously bad english subject line. I will give you points if english isn't your first language but "Does nobody"? How about "Doesn't anybody care about writing good code anymore?".

Hey Robert, you need to learn English grammar *and* how to spell English.

Actually, "Does nobody" is more elegant than "Doesn't anybody" -- and it's good (if old-fashioned) English.  It's just no longer colloquial; so what?

I, too, am frustrated by this phenonenon, as I prefer writing and reading good code.  When I solve some unnecessary ad-hoc puzzle that some earlier programmer unintentionally created for me, I get paid but where is the feeling of enlightenment or personal growth?  The effort I spend reading a well-written program will improve my own programming abilities -- or at least help me better understand the employer's business.

However, I already had this complaint thirty years ago.  If industry hasn't learned by now, then perhaps it is we who are not seeing the big picture.

Sure, you can argue that the effort put into any long lived piece of code would have been far less had it been well-written from the start.  But long-lived code is only a small fraction of the code that gets written, and you don't know ahead of time which fraction of code will be enjoy long life.

You have code that it written and then thrown away when managers realize that what they told you to build is not what they want after all.  You have many bits of perhaps well-written code contributed to a project that fails other developers could not complete their part of the project.  You have code that it written and then tossed when a company is acquired by a competitor with its own software infrastructure -- and wants only the customers and non-software patents of the aquired company.  You have code that it written and then tossed when a superior commercial software package replaces it (e.g. payroll is replaced by PeopleSoft).  You have code that is written and then replaced when maintenance programmers are no longer available for that technology.  You have commercial software that is built and then abandoned when a competitor achieves market dominance.

In other words, most money spent on developing code is wasted, and you only increase your waste if the abandoned code was invested with high quality.  A small percentage of code provides the benefit that makes the crapshoot all worthwhile -- and the employer is willing to put up with high maintenance costs to minimize his losses in all the bets that failed.

So what can be done by those who care about code quality?

(1) Develop skills that are so superior that you can write good code as fast as your competitors write bad code.

(2) Learn to improve code incrementally rather than through a comprehensive rewriteng.  Then improve it a bit at a time.  If 20% of the time you spend on each small task is used for refactoring, your boss will still see steady progress in  new feature implementation, and you can improve the code without anyone being the wiser.  (This only makes sense if you now _own_ the code, so that you can gradually start winning back the time as future tasks become easier than they would have been.)  This is also safer, because halfway through a big rewrite you're likely to discover a subtle requirement that invalidates your approach -- and that some of the code's ugliness was a clumsy but successful approach to dealing with this requirement.

First of all, as a Java developer i can say, that bad code isn't a matter of the chosen language ...

Secondly, it's kind of kinky that it's always 'no time' for those techniques (e.g. refactoring) and design principles (e.g. loose coupling, single responsibility principle, dependency inversion principle) that could support a constant development rate.

How many times have you heard 'yes we should refactor this part of the system when we'll have more time'? The funny thing about is, that your design debts grows bigger and bigger until a 'point of no return' where the code base is in such a state, you can't refactor without an immense amount of time, so that reimplementing the system would obviously take less.
Trust me - with this kind of attitude, there will never be 'enough time'.

Not for nothing there is a well known dictum for this kind of development style: 'fast, slow slower'
(first iteration / release may be fast, but following releases are in need of more and more time in order to implement the same amount of functionality because of the disrespect of the mentioned techniques and principles).

Greetings

Mario