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?

11
  • 1
    ...see also: How do I explain ${something} to ${someone}?
    – gnat
    Jul 4, 2018 at 15:37
  • 4
    This is a technical site, not a persuasion site, and your question is very light on technical details. I sort of wonder how great your approach is if it takes five times the amount of effort to complete a task; your management will wonder the same. Jul 4, 2018 at 15:48
  • 2
    It's also expedient. Convincing management is simple; you have to prove that your way of doing things adds more value than the 5x increase in cost. Jul 4, 2018 at 16:07
  • 2
    That said, 5x is a lot of additional cost. It would take a lot of convincing anyone (including me) that the additional cost is worth it. Jul 4, 2018 at 16:19
  • 1
    So... your team committed themselves to delivering something on a preset moment, close to that time you started making up excuses for not going to deliver after all and some other guy fixed you up with something to save your face before going on with his own responsibilities, and now you hate him for it. I bet some people are thinking you're all mouth. But then again, they don't understand what it's about, they are as stupid as management. Jul 4, 2018 at 18:57

2 Answers 2

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.

7
  • The OP suggests that, while the code is spaghetti (in his opinion), that he actually does understand it. Jul 4, 2018 at 16:15
  • Some of what you wrote applies, but the problem here is that the cowboy is not cooperative. He did it behind our backs just to prove a point or something. He rarely writes code anymore and is more of a project manager these days, so he will not have to deal with any consequences of the bad practices he uses.
    – JohnEye
    Jul 4, 2018 at 16:25
  • @JohnEye it's your job to make him cooperative. He's proved his point. You need to learn from it. Make him a mentor. He's coding this way for a reason. Find out why. Find out if you can code this way too. Find out what doing so will cost. Don't try to convince him of anything until you do. I can code either way and my biggest consideration when choosing which way is how the other coders feel about it. Jul 4, 2018 at 16:45
  • 1
    His coding style is pretty much what mine was when I was just starting my career, and I don't think I became all that dumber with the years of experience. Of course I can code like that too, and I have worked with many projects which were written this way, always as the poor sod tasked with fixing that crap up. So I ain't budgin', I'm finally working with new code and will not repeat the same mistakes I've witnessed over the years.
    – JohnEye
    Jul 4, 2018 at 17:22
  • 1
    I've had decades more experience then some of the people I've made into mentors. He understands the code as written and can be productive in its style. You are threatening to remake part of the code in a new style that he won't understand, want to take forever doing it, in the name of "code quality" that you haven't justified the value of. Sorry but if you want a revolution invite him to be a part of it. This is about the humans. Jul 4, 2018 at 17:53
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.

1
  • 1
    Of course I can out-compete him in the long run, but that sort of depends on keeping the project alive until it becomes clear that this is the right approach.
    – JohnEye
    Jul 4, 2018 at 17:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.