Software development - The industry & general trends / Bad practices [duplicate]

Question

I am a Web Developer and part of a small team working on an abundance of projects. This is my first "actual" real company after graduating with a degree in computer Science and I have about 2 years Asp, SQL etc experience.

I'm going to try to get straight to the point here. First of a couple of things:

1) We NEVER comment code. "Commenting code is for the weak" are the exact words, and we can rather use that time we would've spend on inserting comments here and there on churning out more code.

2) We don't do documentation. "We are IT guys" and we don't need to document stuff, we remember it automatically.. (Not my words)

3) We NEVER have code reviews and or meetings. Thus anyone can commit anything to the SVN repository. We have such a lot of projects, the chances another developer will ever see your code is highly unlikely.

4) We don't do unit testing of any kind. We have "testers" which aren't dedicated testers, rather ambiguous department responsible for project management etc. They know the system really well so they can do front-end testing (usually done quickly).

5) We have a "If it builds ship it mentality". I get chills every time I have someone mention this. (Basically we don't care about code quality).

6) Discouraged from asking for help from senior developers, no mentor-ship. We work like machines. As long as you keep churning out code, your okay.

7) Some make code dynamic to the point where no-one can maintain it. No really.. Dynamic SQL inside dynamic SQL inside... 5000 line SQL queries. It literally comes to the point where nobody except the "genius" that wrote it can or wants to maintain it. Sure you want to make code as dynamic as possible, but still it should be maintainable? Or do I have it wrong here?

8) There are no specifications. But when you are asked to predict and make an estimate of how long it will take you to correct a "bug" or do something on a piece of code you've never seen before, you are expected to make an estimation "there and then" on the spot. 2 weeks, 1 day and 3 and a half hours... Nice..Usually ends up being totally incorrect, everyone misses their deadlines thus the business is unhappy.

We are so rushed to get bugs done on paper, that we rush it, commit bad untested code, do things poorly and digging a hole for the next poor soul who has to maintain it.

E.g. I did an enhancement a couple where I added rights for a user function. A couple of months down the line, in came another enhancement assigned to someone else. He actually saw that I already did it, and built another function which just "triggered" my code. Thus we had 2 completely identical functions with different wording. The bug to fix it came to me, and I had to sort out the code.

Another scenario. We started a redo of a project in MVC. Instead of properly researching and taking time to get to know MVC, the dev jumped in and started coding with SESSIONS and hard-coded controls etc instead of making use of html helpers. Layout pages, BundleConfigs and all other essential and basic parts were overlooked. Why didn't we do things properly?

My question:

Is this industry standard to rush things? Even if it means creating a handful more bugs and problems which will cost more time in future to fix? Instead of initially spending an hour or two extra and doing something properly, we have to come back to bug after bug in the end costing us lets say 10 hours of work. (Sure there will always be bugs), but it seems the guys getting the praise are the ones committing horrible code, and creating headaches for everyone. It seems there is little place for someone who take things a little slower and lays down a solid base.

Furthermore, is it industry standard not to do testing, comment code, create documentation etc.. ?

I am a little bit frustrated at this point, don't quite know where to look..

I would appreciate any comments or opinions.

EDIT:

I guess my question has been indirectly answered. I am curious as to the general industry and other companies? Are all companies geared this way? Is there light at the tunnel, if say you go work for a big player like Microsoft or Google? Do any companies out there still bother with unit testing, code reviews, other performance reviews or code quality practices? It seems the answer from the other articles is sadly no. So, how I want to distinguish my question from the other existing questions is, I want to know what does the grass look like on the other side? Other companies?

Answer 1

Is this industry standard to rush things?

To some degree. Companies are in business to make money, and (almost universally) business people want things faster - even at the expense of some hand-wavy quality.

Furthermore, is it industry standard not to do testing, comment code, create documentation etc.. ?

At my current company, we have no QA department. I've heard of a few others recently that also do not. There are a number of arguments. Having a QA department means that developers are more likely to overlook quality since it's "not their job". Having a QA department is too costly for the number of bugs they find. Dedicated QA people are largely horrible, so why bother?

It's decidedly debatable if that is a good idea. It is certainly not standard.

"Commenting code is for the weak" are the exact words, and we can rather use that time we would've spend on inserting comments here and there on churning out more code.

What sort of comments do you expect? Certainly some well placed comments are good, but javadoc style comments are increasingly uncommon. Comments won't help if your class/function/variable has a bad name. If you have good names, comments are duplicated effort. If you have bad names, comments do nothing but waste time better spent on fixing your names.

"We are IT guys" and we don't need to document stuff, we remember it automatically..

While I disagree with the reason, documentation is decidedly uncommon in many industries for good reason. It's costly to create. It is invariably out of date or incorrect. And you often need to duplicate it for various target audiences.

We NEVER have code reviews and or meetings.

Almost all industries will have some meetings. Code reviews are less common, but maybe not as necessary as you might imagine. I've worked in a few places that require code reviews, and probably 75% of the time, they're completely worthless. Process for the sake of process. And that's at places that do code reviews well. If you don't have the skill/patience/communication to do code reviews rather than nitpicking useless stuff or taking turns criticizing each other...

We have a "If it builds ship it mentality"

Awesome. This is fairly common these days since gated check-ins and automated test suites can provide high confidence that building code is working code. ...though it doesn't sounds as though you have that sort of infrastructure.

There are no specifications.

Sadly, also common. If you're doing agile well, then your specification is the code, which you build up day by day and week by week working closely with your stakeholders. More often, it's an excuse for business people to not do their jobs.

That said, your argument about estimates is fishy. What makes you think that specifications will make your estimates better? They're likely to change anyways...

So what you describe sounds like a crappy, non-standard, dysfunctional environment taken together - one that expects people to pump out crappy code with no long term view. But in isolation, some of the things you have problems with aren't so much problems if done well, or not the cause of badness you see. And even this sort of short term coding view can be viable in businesses where the code will be thrown away, and/or time to market actually matters (which is far, far less than business people think it is).

Answer 2

Look at it with the business eyes: either, this way of work is wrong, it means sooner or later the firm won't be able to find developers, or to hire enough of them to fix all the unmaintable code. Or, the code still generates enough money for the firm to survive. Therefore, there's nothing wrong.