How can I change sloppy company culture? [closed]

Question

Sometimes when I have a problem that needs to be solved, I find that the easiest way to solve it is by writing a small program as a personal tool. I don't make it super usable or super robust, as I am the only one going to use it, and I don't have the time to refine it and test it thoroughly.

Then a coworker sees the program and asks for it, because he has run into the same problem and the tool could help. I give him the "It's not pretty but it'll get the job done" disclaimer and let him have it.

Next thing I know, my superior is calling me, telling me that he's trying to get the software to work on a client's computer but it's showing X error message. WTF?? That software is not ready for release, nor was I told that it needed to be ready for release. But for some reason, my superior thought it was good enough and released it without telling the original developer.

Now, this particular problem is easy to fix with a MessageBox.Show("DO NOT GIVE TO CLIENTS!");. However the problem is indicative of a much deeper problem: our company culture is sloppy. Sloppy software is OK and sloppy processes are OK. Don't worry about the future - put just enough effort into getting it barely working now, put the binaries in a .zip file, and ship it. Good enough for government work.

This is a small company with 10 full-time employees, is growing, and has been around for a while. Don't get me wrong; I love working here and I love the company. Don't tell me to run; I want to be a part of making the company better. How do you start to bring good change to this kind of culture?

Answer 1

The only way to change is to make everyone else see the downsides of a sloppy culture and, perhaps more importantly, have management buy-in to fix it. In reality though, that doesn't happen and you won't be able to change it. That might not be the answer that you were expecting to hear, but after five years or so of trying and failing at several jobs to change sloppy culture, I can say with some authority that it's usually not worth the effort to do.

The first step would be finding out if anyone else knows or cares about the sloppy culture; if you are the only person that sees any problems, your efforts are in vain.

Answer 2

You may need to have a sit-down with co-worker and boss and explain that you what you had was a prototype and wasn't ready for clients to use. If they wanted it to be ready for clients to use, you could make those changes given enough time but please don't take the "quick and dirty" stuff and pass it along to customers. Just because something works doesn't make it good being the lesson to learn. While you gave a disclaimer there is something to be said for giving it some respect as otherwise this is what can happen.

Answer 3

You cant fix stupid. If your boss is doing things like you describe its unlikely you'll be able to change that. Especially if he's not the owner - remember, he has pressure coming from the other direction, and that direction signs his pay check. Same with your other co-workers. The best first course of action you can take is to get in the habit of protecting yourself. Use such techniques as that message box you describe. Keep all emails. Get as much as you can in written form. This way you dont take the brunt when stupidity strikes. Then, as you get promoted up, institute the changes you want with those under your supervision.

Answer 4

The other day, a colleague told me a story of a simple test tool to allow an engineer in a lab to issue a single command to a widget, and change a variable that goes with the command. This was written 9 years ago now, and last he knew, it is still in use today. A tool that was written in a couple of hours with minimal testing to prove, in the lab, that something works, was the basis for an entire engineering laboratory test tool. Once you write code, it exists. If it does something useful and it's seen by other people, people are going to want it. If it's good at what it does, people are going to ask for it to do X. Next thing you know, your simple tool is a significant component.

I think the first responsibility is on the software developer to make sure that anyone who looks at the code or uses the tool understands that it's a prototype or not a production system and say why that's the case. It sounds like you did that, however your coworker(s) neglected to carry on that responsibility. In order to address this, I would recommend speaking to them, reiterating that this was not production code and was only written to facilitate your work. If they find it useful, perhaps offer to work on the tool or support other people working on the tool to enhance it and make it more suitable for production.

As far as organizational process or culture change, expect it to take a while. Start by setting an example. If you haven't read The Pragmatic Programmer, do so. Take note about tips such as Care About Your Craft, Be a Catalyst for Change (show people better ways), Don't Live With Broken Windows, Fix the Problem Not the Blame. It sounds like you recognize some problems addressed by these tips, so start working and living an example to your colleagues.

Answer 5

Until decision makers no longer tollerate the consequences of the bad code and are willing to pay/change their ways to fix the problem.

These are difficult decisions for small and growing companies. They don't know where to put all their efforts. There is a risk making code too robust when business rules and sometimes entire lines of business appear, change, and disappear over-night.

Strive to write good code. Make sure you inform everyone of the consequences so they can make informed decisions. If bad code gets put into production, keep a close eye on it if you can and continue to suggest improving it especially if that part of the business becomes critical.

Making people wait for what you see as minimally viable code seems to be beyond their current expectations.

Answer 6

I'd point out that part of the problem here is that you've written a quick and dirty tool in the first place. Granted, there were good reasons. Granted, it did the job. But, I've found that anything that solves a problem, will fall into the trap of a "good enough" solution, if you start passing it out.

If your fellow wants it, either politely tell him it isn't fully functional, and you're keeping the keys. You can run it for him from time to time. Or, add in the extra functionality, preferably from the beginning of the project.

All of my quick and dirty tools at this point come from a heavily tested skeleton file. It lets me get going quickly, provides me with a working starting point, and lets me forget about adding all of those necessary blunt edges. I don't have to worry about the getopts library, and its quirks. I don't need to remember details about memory management when I use python. Build the program so that it does one simple task and only one. That makes it easy to test if they are trying to bend it out of shape.

Finally, take advantage of finite state machine architecture. If you know going in all of the possible states, it is far easier to make sure that no matter what, the user can never jump the tracks. I have a program that I wrote to follow this paradigm. It accepts arbitrary input files, which it reads through byte by byte. Even if the client told it to read a binary executable, it wouldn't have any problems. Since it wouldn't find any of the things it's looking for, it's internal buffer would fill up. That would cause it to gracefully clean up, close down, and report to the user that they need me to look at it.

Answer 7

Well, the answer doesn't have much to do with programming, except that software is a good that it is difficult to easily judge the quality of.

You might not be able to change the culture, because people may have no real motive not to be sloppy, because the people affected by the software quality don't have much to do with the process. For example, your clients might be required to purchase and use software to do their jobs, but have little personal stake in how effective that software is, because they won't personally be blamed for it's problems or rewarded for it's virtues (in large part because nobody really knows if competing software would be any better). So you might only have to meet their feature requests without taking too long, but not have to worry much about whether it's buggy. So you can all be fairly sloppy without consequences (to anybody who makes any decisions that affect you).

I don't know if something like this is the case, but if it is you may have a hard time changing the culture since the people you are trying to get to change won't actually be better off if they do.

If they will be better off, you may have an easier time of it, since you can potentially convince them why they will. Unfortunately, if there weren't some sort of political situation that makes sloppiness O.K. they probably wouldn't be sloppy in the first place, so it's likely to be tough. You could always try the argument "someday you may have a job that requires doing things right" (perhaps more diplomatically phrased...)