Endless Loop

October 16, 2013 12:21 PM

Can code quality be brought in to a fast and loose web shop?

This recent post really hit me hard. I'm in the middle of a work situation that is rapidly turning ugly. Some excerpts from the post's comments:

So there's no motivation for a development department to spend the time, money, and effort to improve its level of craft; to anyone outside the department (and to some inside it), that looks like waste.

In software, it's possible for a beginner with terrible habits to cobble together something useful, something that mainly works. In most business environments, that's all that's wanted.

End users care about user experience, not code quality, and the bad thing about programming is you can have one without the other.

I got myself into a bind where, I thought I was being hired to up the game and bring some quality practices on board, and the company thought they were hiring a fast-turnaround/low-qual errand-boy (with LOTS of experience, yo). They give lip service to quality (their catch phrase is 'premiere'), but (a) they are basically ignorant of what good architecture and code looks like (b) their (apparent) definition of quality is 'functionally correct, pretty, client likes it'. Arg.

So, has anybody sold code-quality improvements to a fairly clueless (but profitable) management tier? What did you do? Or do I just surrender and join the race to bottom?

I guess another option is to find a shop with my same understanding of quality. Anybody ever asked for code samples from the interviewer? Totally serious.

posted by j_curiouser to Computers & Internet (9 answers total)

Best answer: Short answer, no. If you read the daily WTF etc, places like that tend to lumber on.

Want to avoid it ? Well .. That's hard. Commercial software tends to be a bit better than gov't contracting or in-house devs, but all arguments I'd put forth about why are easily countered.

(Commercial has more pressure to profit, but profit means cut corners. Gov't is one customer, and tends to pay for even crappy projects but gov't work attracts those who aren't going to google, and in-house devs are usually seen as just a drain on profit/all-overhead-expense and don't produce value for company)

That said, I'd assume if you've got the experience, you've been around enough to see both "all process, no code" and "no process, shit code" ends of the spectrum.

So an answer that isn't an answer is: leave. DTMFA. Start working on your questions to ask when interviewing to ferret out these kind of places, and find what balance is OK for you.
posted by k5.user at 12:37 PM on October 16, 2013 [2 favorites]

So what's your definition of 'quality', "developer X likes it"? Let's face it, much of what developers try to sell as "quality improvements" is just themselves stroking their egos. What's it going to do for the business? Will it cut down on unbillable hours? Will it enable you to deliver projects more cheaply? Will it enable them to fire a few expensive people and replace them with shell scripts? What's in it for the customer?

I've spent lots of expensive consultant hours improving code quality because the customer valued quick turnaround and we made a convincing case that the time spent on maintenance was an investment that enabled them to get that (we had historical examples to point to, and made sure to communicate when shortcuts were taken in order to remind people that taking them meant technical debt that would have to be paid off some time later). Nowadays, I work at a company where code quality is valued a lot, but it's also well understood that we do that because we're burning lots of expensive computer and engineer time if we take shortcuts, not because of aesthetic preference.
posted by themel at 1:02 PM on October 16, 2013 [3 favorites]

Response by poster: So what's your definition of 'quality'...?

Well, generally pretty mundane mid-level-ish stuff...

- normalize the db (for usually small RDBMS)
- quit building SQL with inline string cat - use SP or an ORM
- adopt practices that tend toward reuse (GOF, SOLID)
- modularize functionality in components that can be portable across projects
- stop embedding business logic in web service tiers, use libraries
- stop mixing business logic in the UI
- unit test
- fundamental web security

Let's face it, much of what developers try to sell as "quality improvements" is just themselves stroking their egos.
hmmm...got an example. Fistfights over indents? I'm really curious, because I think that may be how I'm being perceived, when I'm actually trying to get a better ROI. Technical debt is a thing, and it precludes faster turn-around on new features, extended features, and defect repairs. It prevents portability of components across projects.

I contend that the ROI is in what-doesn't-have-to-be-kludged-in-later.

I don't know what your view of aesthetic is, but normalization's been around since 1977, and SOLID OOP since the late 90s. Even the highly procedural data-oriented guys split responsibilities across tiers (see every SOA developed in 2002). Thoughts?
posted by j_curiouser at 1:44 PM on October 16, 2013

Agree with above. The answer is "no".

Here's the thing, the goal of the business is not to produce quality work. The goal is to make money. If a "web shop" can produce viable results with crap code for as little time as possible, that's what will win almost all the time.

Most businesses need something that works. Immediately. Even with bugs and quirks. That is understandable and is a good business decision.

Some businesses need quality, documented, expandable code. That is also understandable.

I think that 90+% of businesses fall into the first category.
posted by nedpwolf at 1:51 PM on October 16, 2013

Best answer: The only thing you can do to bring quality into the workplace is to generate quality code yourself and to champion best practices as they benefit the business. The problem is that the latter is really a political issue. From the standpoint of engineering and design, many best practices are pure win: automated tests speed up your ability to iterate and deploy good, working code; continuous integration speeds that up yet again; code reviews allow peer evaluation and (when conducted positively) the improvement of team cohesion. However, there are many people who think "just make something that works, don't waste time," without understanding that "working" is a beast with many heads.

In this industry, as a realist who needs money to put food on the table, I've found the best practice is to set yourself a few limits: for example, I will never work at a place without source control again. I just won't. If you think source control is a waste of time, you can go die in the pits of failure yourself. I'm not going with you. Same deal with automated tests. There's research. It's been proven. If your company thinks automated tests are a waste of time, well, good luck. I'm not going to put myself in a situation where I have no way of telling that one of my changes has broken some hideous module on the other side of the code base because Pete the Contractor of Insufficient Skill was relying on the structure of a hash.
posted by sonic meat machine at 2:00 PM on October 16, 2013 [2 favorites]

Best answer: Perhaps the best-known baseline is the Joel Test, which is pretty much an industry standard for evaluating companies. My current company is an 8 or 9. I won't work for a company that scores lower, today.
posted by sonic meat machine at 2:04 PM on October 16, 2013 [2 favorites]

Best answer: Great question— I could have written your post almost in those exact words ("lip service", "asked for code samples from the interviewer")

Like the people above, I'm also convinced that most companies don't realize the value of good code. Many developers don't realize the value of good code. If it doesn't immediately and easily translate to a business goal, they assume that the developer is indulging in some masturbatory urge to indent correctly. If the investment horizon is longer than one sprint, they assume it will never pay dividends. Given the forces working against you, I think it's a huge political task to challenge these assumptions.

The first company I worked for, which is now pretty successful, got this right. Looking back, I think it was because the founder was also a lifelong programmer. It was also an industry that was highly technical (online video), which helped attract talent. It was also in San Francisco, which is a magnet for these kinds of companies.
posted by your hair smells like cheese! at 2:16 PM on October 16, 2013 [2 favorites]

Best answer: You can discover a lot about a development team by looking at the budget. If they have approval to spend money on dev tools, they're usually open to actually using them.

When interviewing, ask about the specs of the dev hardware, the software tools that they use, and the servers that support the dev team (do they have build servers, Version-Control servers (eg: git/svn/etc). Good or bad by themeelves they mean nothing, but they are symptoms and ways to understand the company mindset.

Ask about meetings. Most teams that are actively working on quality will have daily standup meetings, and some form of scrum/agile. Ask if they have dedicated testers and product managers. And ask when their last team building exercise was (eg: did they all go see a movie together DURING work hours).

It doesn't matter if a company has quality code or not, but it does matter if they're actively working on improving and investing in tools and methodologies that can do that.

If you're not satisfied with the answer to any of those questions (or the Joel Test especially), then run.
posted by blue_beetle at 7:59 AM on October 17, 2013 [1 favorite]

Response by poster: Update: Got into a tussle with management because the guy before me copy-pasted a ton of free script-kiddie bullshit into a project, then wrote a 900-line (I kid you not) JavaScript function to call all that crap. I put the PM on the spot about oversight, risk, engineering ethics, and extensibility. I was shown the door...and see that as nothing more than a step up. So, resolved ;-)
posted by j_curiouser at 1:58 AM on May 9, 2014