3

Background: I work for a small company which does not have a set of established best practices for designing software. I was hired to work on a project which gathers data from a stream, does some processing and aggregation and writes it to the database. It should eventually help replace an old system which is basically many thousands of lines of spaghetti code. Together with a colleague, we have designed and build something which I would consider a good base for a system which would be extensible, testable and stable.

The problem: The development of the last feature took about 15 days of work and the situation was looking rather bleak with regards to meeting the deadline when the feature would be demoed to the customer. A more senior guy "comes to the rescue" and builds the same feature in three days, using the same coding style and overall approach as is used in the old system. The result is just as monstrous as the original, but this is not visible to management, who will certainly ask why we're not nearly as productive as this guy. Our solution has actually still met the deadline, but in the meantime the UI was wired to show data from this new solution.

It is very easy to be a cowboy coder and write code with no tests, no safeguards against unexpected situations and no real structure. The new code just darts through the happy scenario and does the bare minimum of work necessary to get the correct (but how do we know?) result to the database.

How do I persuade management that this practice is extremely harmful and that good software engineering will very quickly start paying dividends? Are there any good examples I could mention to support my case?

JohnEye
  • 300

2 Answers2

3

It's not easy to be a Cowboy Coder. Only you understand the code base. Even you get stymied by how resistant your code is to change. And your fellow programmers are constantly whining to management that nothing makes sense.

The problem is that management doesn't understand code quality. They never do. They never will. Why should they? It's not their job.

When my car wont start and I take it to the mechanic if I'm told it will be ready in a week I'm going to be expecting it in a week. I don't want to show up and be told I have to wait a month because starter motors imported from Germany are the best.

If you're thinking of tying up my car for a month tell me that on day one. Once you promise a week you'd damn well better have a way to be done in a week. If I demand it done in a week you better say no now. If you're competing with another shop that guarantees to be done in a week you'd better figure out how you can offer to be done in a week.

What you explain is what they will get if they want it done in a week vs what they get if they give you a month. You don't get to decide this. You need to learn to work both ways.

Give me a crappy starter today and if I care about quality that much I'll be back in a month to get your fancy one.

That's really all you can do with management. Who, as I said, will never really understand.

What you should do is go and learn all you can from that cowboy coder. Stop acting like your books are smarter than that guy. Ask him what problems he actually has now. Ask how he avoids the problems you see in his designs and what he thinks about the changes you'd like to make. If you see a better way don't shame him with it. Show it to him. Let him decide that in this situation it really is a good idea. Make him a partner. Not the competition.

If you don't do this you're going to waste a lot of time and energy racing him and fighting him as you both keep undoing each other's style. Your best solution is to put him on your side before you try to convince management of anything.

If you do code quality right, management never notices it at all.

candied_orange
  • 119,268
1

I am going to play the devils advocate here. I liked the answer from candied_orange; he points out that you may learn something from the "cowboy coder".

I argue that if the alleged "cowboy coder" is truly working with "spaghetti code", said coder is unlikely to be able to able to be more productive than non-cowboy coder working with clean code. And when I say "clean code", I mean it in the traditional sense (as simple as possible), not full of boilerplate and cargo cult techniques such as "SOLID".

Do you think you could out-compete the "cowboy coder" on longer term projects? If not, you need to go back and examine the old code, and talk to the cowboy coder, because the new code is a failure, and the old code may not be as bad as you think. If the new code is better, you will be more productive, because better code is always simpler and smaller. If it is not simpler and smaller, I suggest you rethink your entire view of software development.

Frank Hileman
  • 3,952