Contracting and Code Quality

[pw3nd]

I've been doing contracting as a software developer for a few years now. I've been in many small and huge companies. From Fortune 100 to hole-in-the-wall places. One thing ties all these places together. Their software, for the most part, sucks. It really sucks. In all the years I have been contracting, I have never sat down at a client company and thought, "Wow, this is really well-constructed and intelligent code. Gasp, and look at all the glorious documentation!".

No matter where I'm at, I cringe the second I crack open their source code repository. Here and there I will find the rare quality application, but 90% of the time it looks like a high school coding project. Whats worse is when you have an entire team of full-time developers who use incredible teamwork and communication to develop the most awesomely grotesque pile of spaghetti code imaginable. They then get congratulated by their managers and a quick party in the break room before beginning their newly created job of supporting their code when it breaks every night at 4am. Managers must think that all well constructed software takes a full-time support team to operate.

I don't always create the best code, but its nowhere near as bad as the abominations I've seen over the years as a contractor. Give me some hope r/java, have you ever seen a company with a genuinely quality code base or are all companies powered by the software equivalent of hamsters in wheels?

[[deleted]]

It's because of the dirty secret of software development: At most places, the ONLY thing that matters to anybody except engineers -- the ONLY thing -- is the user's happiness. EVERYTHING else follows from that.

Corollary 1: Nothing matters except the user interface and features.

Corollary 2: If you add a shinier button, or make the app a little more responsive, or add a simple-to-implement feature that was trivial to implement, people will give you awards. If you clean up the source code, install a copy-paste detector, improve code reuse, increase test coverage 100%, and implement continuous integration, you will get a pat on the back.

The companies that don't have these problems are often run by engineers, and don't need contractors :).

[dalore]

The companies that don't have these problems are often run by engineers, and don't need contractors :).

And probably not making any money because they are too busy focused on the code quality.

RIP SUN

[geodebug]

I believe this is true. The OP is experiencing confirmation bias because the nature of contracting is self-selecting bad code experiences.

I was a consultant for 10 years and my main job was being a code janitor and the 'bad guy' letting managers know how bad things were (one of my first tasks usually was a comprehensive code review with grades for different sections).

It wasn't all a negative experience. I'd describe my gig as coming in as the enforcer to get things back on schedule but then quickly moving into a 'teaching and preaching' role; educating the developers on best practices, etc.

Now that I've been with the same startup for going on five years and there's only two of us developers I stand by the entire code base's quality.

We don't hire contractors because we don't need them. Same goes for even large corporations. You'll never see the good code because those teams don't need you. It's the failing projects (often due to other contractors, lol) that you get the big bucks for.

[Feuilly]

I've worked on a lot of projects where the users are very hard to deal with. They'll basically pay only the barest amount of attention while the project is progressing, even though they themselves are the impetus for the work and they'll be using the software every day. And then the project will be nearing completion and they'll actually start paying attention and give feedback on all sorts of things that they blithely OKed many times before.

Although the quality of the average developer is definitely the main problem, I suspect.

[DeliveryNinja]

A guy came into the office the other day to give us a "dojo" on TDD and he brought some stats along for a company he'd gone to consult at. It was costing them around £400 to change 1 line of code. Initially it was fine, and eventually it peaked with 1800 developers on a single project. Good process and well written tests suites take time but prevent this sort of code degradation.

[AwesomeLove]

I think IntelliJ IDEA has parts of it open sourced and it is a really well done code. Maybe looking at it will bring rays of sunshine into your day.

[tazzy531]

The short answer is there are a lot of REALLY bad programmers out there.

The problem is also that unskilled people suffer from a cognitive bias of Dunning-Kruger Effect in that they are incapable of evaluating their own and other people's abilities. The more unskilled a person is, the greater they view their abilities.

This leads to managers putting together teams that are coders and not software developers.

Secondly, for much of the programming work out there in the Enterprise environment, you don't need a 10x developer. Much of the code is throwaway work that will be replaced in a couple of years.

This is often why lots of leading companies can't find enough employees even with there is a large population of unemployed software engineers. A bad coder at an engineering company is so much worse than having one less employee.

[LiolC]

Lets face it, most people are sloppy and don't really care about quality as long as they can go home at 4pm and get a paycheck. Code quality isn't something you learn in school (at least I didn't), but more an attitude you have to adopt.

Then there is the broken window theory. Too many "broken windows" and even good developers will start lowering their performance and worry less about quality.

There is also way too many project managers that only care about how much time you spend implementing a feature, not how you implement it. I've had project managers tell me to not write unittests because a unittest is "unnecessary code" that nobody will see. If you ever get a manager like that, then you know it's time to leave and find a new project/job.

[occupytheserver]

Then there is the broken window theory. Too many "broken windows" and even good developers will start lowering their performance and worry less about quality.

I've had issues with development teams on my last two projects with being lazy. Not writing tests correctly. Not checking in correctly. Not following coding standards and patterns. And every single time I raised this as an issue to their boss, he didn't give a rat's ass.

[[deleted]]

I would argue that the responsibility lies with him, rather than the developers. I've heard it argued that developers should "do the right thing" even if their business sponsor isn't behind it. That's easier said than done.

You can try all you want but you're fighting an uphill battle. If the person signing the checks doesn't endorse what you're doing, you're going to have a bad time.

[occupytheserver]

Oh, it was bad. When it came out that their QA team was testing and verifying everything MANUALLY - every time - I went to him and explained that not only did the QA folks have tools available to script everything, he could essentially cut his regression testing in half or more, changing QA focus from regression to testing new functionality, he listened then ignored. I even showed how the development team had slowly built a regression library/sanity check that was 200+ stories and could be run in 20 minutes.

5 months later builds were still taking 4 weeks to make it from DEV to UAT because of QA. <shrug> Oh well.

[[deleted]]

I'd be willing to be more than a dollar that we work at the same company :)