I've gotten a couple of interviews from companies to fill a junior software developer, half of which are consulting companies.
My last and first job didn't really focus on code quality and was very budget oriented. Creating high quality code is something that I want to practice doing from now on.
So my question is, do consulting companies care about code quality? If i had to guess, i would say 'no' but i could be wrong and correct me if i am.
The #1 objective for a consulting company is to complete the project on time, on budget, and to the client's satisfaction.
Everything else is secondary.
Being concerned about budget and not focusing on code quality sounds like an oxymoron to me.
Because low code quality will in the end bite you in the ass and suck away more cash that you originally planned.
It's not so much that they don't "care" about code quality, it's more that high quality code is difficult and expensive to write (Much more preparation must go into it's design and testing and sometimes then client just wants it in 2 weeks and will accept 98% complete).
A (good) consulting company is going to be concerned with code quality, but only to the point that it makes their client happy. Spending extra time and effort on higher quality code, beyond the expectations of the client, is likely to be valued less than getting something done on budget in a satisfactory manner.
Any company, given the choice, will prefer high quality code over poor quality code - its more a matter of how much time (ie: money) it will cost, and whether the client deems that a priority.
So my question is, do consulting companies care about code quality?
Consulting companies care about what the customer wants them to care about.
In general customers go to consulting companies when they can't do themselves due to lack of resources or expertise, and to drive their costs down.
At the end of the day, however, consulting companies are competing based on cost, not quality, and clients will often choose lower quality if it means lower cost.
So many consulting companies optimize for cost, which often means lower quality.
Some consulting companies will turn down customers not interested in quality, though, and you can determine who they are through interviews. Try Joel's test as a first approximation for the 'good' companies.
I'm a consultant, and I suppose that I, nor my company, lines up too well with the stereotype. We're a small consultancy, so perhaps this comes up more than at a large one, but we make a concerted effort to deliver the best quality code that we can. The rationale for this has a few parts: (1) We take pride in what we do and love every bit of it, why wouldn't we do a quality job? (2) We have to walk away from the project, and our business model is not a host of support contracts. We need to make sure that when we end a project, that code is stable, robust, and usable.
Obviously, budget comes into play a lot, but we that doesn't mean that we can write sloppy code. We meet regularly to improve our coding abilities, and many of us are constantly learning outside of our client work to become better at what we do.
My experience has been that large consultancies are trying to sell as many gigs as they can, and they don't care about quality, they want quantity. But for small consultancies, we live and die by our customer's referrals. Make sure that the people you're interviewing with are the type of people that you want to work with. For me, I found people as obsessed with this stuff as I am, and it's been fantastic.
I'm a consultant, and the basic answer is that ultimately, the client decides how important quality is.
Of course, we consider it very important because quality of work is our best salesman. We get repeat engagements with existing clients and client referrals because we do good work, and so it's obviously very, very important to us. However, the client has to be educated about what the cost of good quality is. Our project management people do a good job of telling the clients up front that we consider it important, and we try to build expectations into the baseline of the engagement. Once we engage a client, our primary job is to make them happy, but we try to make sure that they know they will be happier if we have the budget and schedule to do good work.
If expectations are worked out up-front, then it's possible to have rational conversations about how to prioritize, and the client winds up with high-quality things that they really need, and if there's time/budget left over, a few things they want.
The company is a bit too broad a term. A short answer would be no. The company does not. It's represented by people who usually have very little idea as to what does code look like. There are individuals that wish the code quality was high, and they want this mainly to reduce the time necessary for making changes to the applications. It's up to the individual developers to keep the code clean.
As stated earlier good consultants will do write quality code. However, many consultants don't have to live with the code they generate. What I mean by this is that consultants write code for a company and never have to maintain this code. So many consultants focus on solving a problem.
Companies that hire consultants should have a procedure for internal developers to participate in code reviews with a consultant. Also, you can require consultants to follow coding standards and enforce the use of unit tests. If a consultant is required to write quality code they will write it or attempt to write it. I believe too many companies provide business, system, and functionality requirements to the developer, and then don't maintain project visibility.
At our company we outsourced an project that required a company to create a web application. We discussed the requirements the cost and what the our quality expectations. It wasn't until the project was near the end when we took it over internally. we had noticed none of our coding standards were followed. The application structure was horrible. There were no tests, documentation, or structure to the code. It took us weeks to sort through the application before we understood what was going on. It was soo bad we were affraid to touch parts of the code, because we didn't know the consequence of changing it.
During our rhetorspective we identified our main issue was lack of involvement with the consultant, and lack of visibility. If we were able to review code early and frequent we could have prevented this in the long run. Also, we could have enforced our coding standards. Also, had a developer or development team representative participated in the project we could have made recommendations and had them write unit tests.
The key point is that there are things the company can do to enforce quality code. It isn't just the consultants responsibilty it is the company's responsibilty as they are the ones that will live with and maintain the final product.
Also note that every consultant is different and has a different skill levels and understanding of code quality.
Read up on quality. I suggest Quality Software Management, by Gerald Weinberg. Quality means value to someone. Consultancy companies have a very clear view on value, and on someone.
I would say yes, but it depends. I would argue that if source code is part of the deliverables, than a consultant would deliver the highest quality code that he/she can manage including good documentation. After all a consultant wants repeat business and bad code will reflect poorly on him/her.
If a consultant is delivering an executable, however, then that opens the door for shortcuts including delivering poor code.
I have done a number of consulting jobs in the area of scientific software. In this area the standards are high for both the scientific and the software component of the deliverables.
Having previously worked as a software consultant for several years, I can say that while they do typically care about quality, it's certainly not their highest priority. At the end of the day, they are there to make money, so they are going to optimize their development process for cost. And what that typically means is lower quality. Typically, consultants will not be involved in the ongoing maintenance of the application, only the initial development, so they have little concern about how difficult their code will be to maintain.
This is a large part of the reason why I am no longer in the software consulting business. It was supremely frustrating to see us throwing best practices out the window in the interest of completing the project.
Several people have mentioned having a strict contract that specifies exactly what is meant by "quality" code, but unfortunately it is very difficult to quantify quality code in any meaningful way. This means that the consultants can usually talk their way out of most any of such "quality" stipulations in the contract. We use software consultants on a somewhat regular basis where I work now, and I've only seen once instance where we were able to successfully withhold payment due to poor code quality. And this was bad code, I'm talking epically bad.
Early in my consulting career, I saw a sign in a shop that said "You can have it fast, you can have it cheap, you can have it high quality. Pick any two."
That pretty much says it in a nutshell. Consulting is about balancing the priorities, costs and expectations.
So yes, you can have a consulting company focused on quality code - but only at the expense of one of the other two items in the above list.
Cheers,
-R
Consulting companies generally focus on billable hours.
Connections and a track-record of solving business problems will likely increase future billable hours.
As developers, we are often focused on "code-quality". What the client wants is to solve a business problem, and perhaps to have pleasant, or at least professional, people to work with.
That said, the larger consulting companies with good credentials and track records, tend to develop reputations for utilizing a good development methodology, and will try to create high quality code. The best consulting companies will likely combine high software quality with excellent PR/marketing/relationship building.
Make Quality a Requirements Issue. Seriously. If quality is a requirement (as it typically is), bake it in to the contract/project.
The rational answer that I see repeated often is that the consulting company cares if the client cares, and that since clients tend to
it follows that the consulting companies mostly do not care.
That is the theory, and as we know in theory the practice should be the same, but in practice it isn't.
From what I have seen in the real world the care for quality is part of the DNA of a company. They can't help it. It's cultural and they can't change it from project to project to please the customer. Some carry it as a value, some couldn't care less or are even hostile to the idea of producing quality (you'll here the phrase 'gold plating' bandied about frequently).
If quality in your craft is something that you care about, look for a company that does carry this attitude. You will not be happy and get fulfillment from your job if you and your company are not aligned in this.
I've been employed in a consulting firm with practices that tried to improve code quality, such as:
I can say without doubt that our resulting products were more performing, robust and bugfree than other firms working for the same customer.
The focus is on getting things done as has been said. My first job hired a consulting company to do the web front end. They had this giant piece of javascript/asp code that was very poorly written/hard to read with a ton of functions that we did not require. Basically the guy said it took him two days to do it. What obviously happened is they took this giant piece of code, commented/disabled features we didn't need, and tailored it to our company's specific needs. The code is a mess and very hard to understand and a lot of the javascript had errors (like looking for something, then setting a done flag, but not breaking so it would continue to iterate and end up with whatever the last item was instead of the item that was found). Over time large parts of it were rewritten. By it did satisfy the terms of the consulting contract. Get the front end done quickly.
In particular in consultant code (at all 3 of my jobs to date) I do tend to see "cut and paste" code everywhere instead of abstracting things with a function/object/data table/etc.. For the first time (unless you are cutting and pasting 100 times) the cut and paste is faster. On maintenance or even comprehending what is going on later cut and paste hurts bad.
But imagine you have 20 slightly different ways to display a web page. You could have 20 if statements with the entire page meaning any changes must be replicated 20 times. Or you could have multiple if statements so to add case 21 you may need to change 2 or 3 giant 20 part if statements....Easier might be to use a database table, text file, etc. and a single function to read the definition and take the appropriate action in place of each if statement. But in order to do the latter you need to spend some time thinking about things and how to abstract them. Also if you abstract wrong you can end up with the if statements anyway. And often when you are over budget the attitude is just get it done. Don't spend time abstracting, just do it....If statements, whatever it takes brute force it!! Even with tailoring the software, the company doesn't want to spend time inventing abstractions and designing parts for a client. They just want to brute force, get it running, and collect $$.
So basically for me consultants = lots of cut and paste code. It may have been beautiful once (in their ivory tower) but the real world and customization often totally messes it up. I can even see the thought process sometimes on SQL queries. Instead of maybe adding a new column and a case statement to a single query they will cut and paste the same query, do a union or something, and get the data that way which is a maintenance nightmare.....