How do software development methodologies fit in the field of consulting?

Question

I work for a fairly small consulting company, roughly 100 employees, and I've been with them for about a year currently. This is my first job out of college. As a company we do not specialize in any specific technology, but my day-to-day usually consists of some sort of .NET programming, whether it be ASP.NET, custom SharePoint development, etc. Our projects generally consist of adding features to, or expanding, a client's existing code-base. Rarely we will build web applications from the ground up.

Something that has been bothering me is the distinct lack of any sort of methodology or framework that helps us deliver quality solutions to clients. We do not conduct code reviews, the testing we do seems weak, technical direction seems lackluster. It seems that little effort is made to ensure the code the team commits to a project meets any sort of standard of extensibility and maintainability or adheres to any best practices for the given environment. From my experience thus far, leaving that responsibility solely up to the individual programmer yields some lackluster results especially when inexperienced members of the team are involved.

I would like to know if this is business as usual in the consulting world. If you work at a consulting firm, I would like to hear about any techniques, processes, or approaches that are used to make sure the solution your team is developing avoids becoming a mess, all the while under the restriction that you are working on a client's existing code-base that you may not have complete control of. What can I do as a junior member of the team to promote a culture of producing better software?

Answer 1

The problem with consulting is that you're quite often hired as a monkey to clean up the problems others left behind, add some features or do support that they can't or don't want to do themselves. At that point frameworks, best practices, ... are usually thrown overboard. But delivering good results (read: in the perception of the client, not necessarilly good code) opens new doors at the same client for continued maintenance on the product you're working on, or on new developments from scratch. And that's the point where you can start using an own framework and methodologies from the start.

That doesn't mean that you can't apply e.g. Scrum for your initial maintance/extra features. It also doesn't mean that you should hack away and produce dirty code because it's consulting and it might be a short-term job. I always work in the perspective of "I'm delivering good work, so I'll have to continue to maintain it, so I want to be sure at least my own code is good and easy to maintain". It's your job to keep your own code maintainable and of high quality and only then you can start to expand to the rest of your team.

If you manage to deliver high quality software and documentation and are open on the time needed and deadlines to the client from day one (and not lie to them until the last day and then miss the deadline by miles), you will succeed to deliver higher quality code (it might take some time for them to get to the point where they see the initial extra time investment outwins the time needed for fixes).

That's how I do it, and so far it's been a success.

Answer 2

From my limited experience - I spent 8 months being called a "Consultant" in the consultancy part of a large corporation earlier in my career.

The reasons companies hire consultancies to look at coding issues are

1. They want a broad overview of another companies work, they want to investigate whether it's the best solution. The code involved in this is often demonstrator software, with report and data backing up.
2. They want to short-cut an actual development process by hiring a consultant rather than a proper dev. company. Normally when the job is supposedly easy or hack-y, or the application is a legacy one.

In both the above cases a full development process start to finish is seen as unnecessary expense. So yes from my limited experience consultancy level code is produced t a far lower standard.

As for the second part

What can I do as a junior member of the team to promote a culture of producing better software?

Joel Spolsky produced a nice article on this sort of thing way back when. I doubt I could write it better.

Answer 3

I would like to know if this is business as usual in the consulting world.

No. But.

There's a difficulty.

If the customer has no (or worse, a random in-house) methodology, it's very difficult to impose order on their chaos.

Some customers claim to have a methodology, but really behave quite randomly.

Some customers have a published methodology but don't follow it; it amounts to chaos with guidelines.

However, we use Scrum for many projects. Some of use use TDD, also.

Answer 4

Consulting companies usually charge by time. They may charge for selecting and setting up a framework. If not, it is somewhat to their advantage (profit) not to be to efficient. If they are working on fixed price deliveries the economics change.

I have worked for and with a number of consulting companies. Normally part of the delivery consisted of setting up standards, methodology, and frameworks.

From a client perspective, I would expect the consulting company to have these in place, and use them unless they conflict with internal standards, methodology, and framework(s). Unfortunately, this is rarely the case.

When participating in a software quality group with members from several consulting companies, I asked the obvious question, "Do any of you use your companies methology?" The answer was generally "No". Many practitioners where aware that their company had a methodology, but many had not seen it.