Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
8  
Old Russian saying "A fish stinks from the head!"! –  Jarrod Roberson Oct 12 '11 at 20:21
3  
One time you can guarantee process will be implemented is after a major cock-up. Part of the fallout will be that clients will demand a review of processes to ensure it doesn't happen again. When management find out things like this are happening you'll soon find some shiny new process in place. Maybe you could engineer a cock-up. JOKE! Please don't take seriously :) –  Paul T Davies Oct 12 '11 at 20:45
    
It sounds to me like this should have been a test (unit or integration) instead of an application.... –  devlife Oct 12 '11 at 20:55
2  
I don't want to offend you, but are you contributing to the sloppy culture yourself? If you're talking about a problem that's experienced by both clients and by team members, maybe an off the cuff tool that only you have isn't the least sloppy solution. –  Dan Olson Oct 12 '11 at 22:36
    
@DanOlson You're absolutely right, but at the time I didn't know the clients would need it. If I had, I would have turned it into a full-blown software project. –  Phil Oct 13 '11 at 14:21
show 2 more comments

7 Answers 7

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.

share|improve this answer
    
+1 for getting management buy in. I find that without higher authorities giving the go ahead and putting pressure on something to be done most people will not be willing to change and stick to what they are currently obliged to do. –  dreza Oct 12 '11 at 20:05
    
+1 for the same reason as @dreza. But good luck with management buy in. –  talonx Sep 27 '13 at 7:54
add comment

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.

share|improve this answer
5  
As the OP, I would like to see an explanation for why this was downvoted. –  Phil Oct 12 '11 at 19:53
3  
not to mention that quick and dirty stuff can still hold vital info that should never leave the building (hardcoded passwords for testing for example) –  ratchet freak Oct 12 '11 at 22:19
add comment

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.

share|improve this answer
    
+1 for a sober and practical strategy. –  talonx May 21 '13 at 15:36
    
As much as I agree, it is a sad strategy after all. Who wants to work in such an environment? Such culture will silently kill creativity in the long term. Try to be the best you can be, not the most protective. If the culture doesn't fit anymore, move on. –  JensG Dec 17 '13 at 19:12
add comment

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.

share|improve this answer
    
I'm totally agree with you. My idea is, when you write code, write as well as you can, it usually requires same time to write bad code. Quality is something that you can't obtain in the middle of your project. –  Andrea Girardi Dec 18 '13 at 7:40
add comment

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.

share|improve this answer
    
+1 for "Making people wait for what you see as minimally viable code seems to be beyond their current expectations." Sadly true. –  Phil Oct 12 '11 at 20:44
    
@Phil - and most of them just don't want to get into the details. Sometimes you can tempt them with the ability to easily make changes in the future, security or handle more users. –  JeffO Oct 13 '11 at 0:03
add comment

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.

share|improve this answer
add comment

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...)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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