The Joel on Software Discussion Group

We've got people in various areas adding code to our websites which is truly the worst insecure, spaghetti code you've seen.  Believe me, it is truly bad.

I've complained but have been unsuccessful except to be known as a complainer. My fellow developers agree and dislike it but just wallow in their dissatisfaction.

I plan to create power point presentations on sound principles such as DRY, encapsulation, loose coupling and high cohesion, modularity etc. I'm thinking of titles such as:

Encapsulation: Learn its value from real examples in our code base

Then I'd show samples of our production code which is violating the principle I want to explain.  I would rewrite the code  according to the principle I am highlighting.  I think the authors of the code might not get it still but I'm hoping other people such as analysts and managers will recognize the value of the code written according to principle than stream of consciousness.

Anyone ever do this with success?

>but I'm hoping other people such as analysts and managers
>will recognize

if you can't convince the programmer's of the value of proper code, good look convincing managers. With code demos of all things.

I know where you are coming from, but doing a presentation is not going to work. There's none so blind as those who don't want to see.

Sometimes, it is necessary to realise that things are not going to change, not matter how hard you try. Indeed, as you have already discovered, doing so can make things worse and brand you as a trouble-maker.

If you can't live with things as they are, it is time to dust off your CV and look for another job somewhere better. I have worked in a few terrible places that would score zero on the Joel Test, and it is hard if you get too involved.

Back to the original question:

I did a one page presentation about code quality once. The IT manager of a client asked me to check the security of their new website, as they were worried about hackers. It was already live, so I was surprised that they hadn't already done a security check on it.

I have no background in security, but I thought I'd have a quick look and fired up the site in the browser.

I was greeted with the standard username/password boxes, so I entered a single quote in the username box and a double quote in the password box. You can guess what happened....

I sent a screenshot to the IT manager, with an explanation of my five seconds of "hacking".

Seams like a good idea.

The only problem I see is that the people whose code is going to be criticized may not find it very funny.

So I would suggest one of the following options:

1) Choose code from people who are not in the company anymore

2) For each example you pick up from the code base, you could schedule a "pair refactoring" session with the author, assuming you have the authority to do this (or can convince management about it's utility). As you do these sessions, you would explain to each author why something is better than the current implementation. From this discussion maybe some of them can actually convince you that their choice was not so bad when they implemented it. Your sessions would then be called "How we improved the Design of ...".

Doing something in a not so proper way does not imply that the author does not care. Not everyone goes home to read books and blogs about programming best practices. So some of those authors may actually be interested in learning better ways. I think the "pair refactoring" sessions are better for this than public criticizing or embarrassment.

The authors of the code you choose to display might well be aware that they haven't done it right, but might have been pushed to "do it for tomorrow" and had to hack something quickly.

By publicly humiliating them in front of their peers and managers, you will earn the reputation not  of a troublemaker but of an arrogant p**ck.

If you want to lead, lead by example first, criticism second. You may want to code something correctly, and afterwards make a presentation about the benefits of doing things correctly, comparing it to carefully prepared hacked-up, spaghetti-code version. Make this second version look like the code written in the company. The usual suspects will get the message and internalize it, without feeling offended. You may put it like "this is how I did it at first, but then I noticed such and such problems, and thus I rewrote the code to look like that, which has such and such benefits". Even if everyone knows its a lie, you'll come across as a diplomatic person.

You'll only get fired. (Read the post where a reader from this forum said the truth to his boss.)

Anyway you'll feel relieved, get a lot of enemies and nothing will change.

Thanks for the good feedback so far. I do not plan to say "hey look at what Joe did, he should have done this".  I am working on my powerpoint right now. My subtitle is "Why you should care what is under the covers". Let me give some more background.

I really like working for the company I'm at. This company does great things for people. A lot of people at this company must and do top quality work. It's just that my area in IT is  not working any where near that quality level. I feel like a parasite. I want our group to do top quality work as well. As you can imagine the company line is that this is the goal. And there are groups of people meeting that.  For some reason our local management does not perceive the poor quality or they blame it on our not having enough resources.

The people making changes to the code are not developers. They think they are but they are not. One of them used to be my manager. He has all local upper management convinced that he knows all the technical details. He'll put up a web page doing crud (no framework ... no way) and wow his fellow managers. Never mind that he has sql embedded with html and no input validation thus subject to sql injection and data corruption and never mind how you will evolve the spaghetti code down the road. He also has contractors working for him who have the most basic understanding of programming. You guessed it, PHP. They even embed display details in the html elements rather than use CSS. Imagine the rework when they want to change the look and feel down the road. Nope .. you won't just have a few core templates and css to change. Instead you'll have a mess.

I've worked in maintenance/evolution programming for the last 10 years. The best I get to original development is how to refactor the spaghetti. When I first came to his place they had countries defined in 5 different html forms. I cleaned that up by defining them in a function and provided a flexible call system to get the countries in a variety of ways very simply. I now find that these other developers are now cutting and pasting the html output they see on my forms and using that in theirs so now countries are getting redefined. It boggles my mind.

As I said, this is a good company and I have no intention of having some people drive me away by their poor sense of quality. 

And yes, some of them might really appreciate the education.  My old manager just doesn't get it as I've told him this time and time again. I think there must be a block in some people as they don't grok something as simple as a function.

As noted from above, I'm going to really put the emphasis on learning and not a witch hunt. I will not identify the owner of the code and I'll probably find something I did which could be improved. Truly the goal is to move us up the quality ladder.

Until you have a sponsor in management, you're going to be pissing into the wind.

So I would look for a manager/executive who in new to the organization, and might be receptive to making some quality changes.

If you find one, great.  Otherwise, time to polish the resume up some...

Don't forget that a best practice isn't *always* a best practice.  Sometimes the ugly ugly hack really is the best solution.

Don't be proper for the sake of being proper, do it because it helps you towards your goals, and abandon it if something less proper helps more.

No matter what your intentions, you're going up against human nature  here.

I can guarantee two things...

1.  No one is going to appreciate your presentation.

2.  When you're done, no one is going to appreciate you.

Do the best job that you can do, and let management handle improving quality... if they ever decide recognize that they have an issue and/or decide it is a priority for them.

Hi,  a few poeple have mentioned that sometimes ugly is the best solution. It's a good point and I don't disagree.

I'm not arguing for anything other than common sense. I can show that code done another way would be more secure,  less buggy and easier to evolve and could be done FASTER ... the only requirement is knowledge. I would argue that any good developer would be pursuing this knowledge. I would then argue that these people should be in the developer group so they can learn and grow.

I'm talking about people who wouldn't know sql injection or mail injection if it stuck them in the nose. One of them  actually allowed a hacker to deface one of our sites but it was quickly remedied and I kept mum about it. This person has not learned from that experience.

I'm not going to polish my resume. I'm either going to make this work or get fired and then polish my resume.

Try approaching it this way: why will doing it your way either make the company more money, or keep them from losing money?

If you can't answer that question, then don't bother, because when you get down to it, the code is there to support a business model. If you can't show positive ROI, then you're wasting time.

I'd try to do a document, not a Powerpoint presentation. And discuss it privately with relevant managers at least at first, not present it to a wide audience.

If managers aren't willing then to promote good practices it would be time to move.

The way to present bad news is to provide a way out that makes everyone feel a little better about it.

I once gave a presentation to the developers and management at a company I worked for where I literally tore our main product to shreds from a customers' perspective. Most of the UI flaws exposed were due to the dev team taking shortcuts (e.g. lack of forethought over how people would actually interact with the system, overuse of MessageBox() etc.). Certainly nothing particularly unusual - but we were starting to take a beating over it from some customers.

That was probably the most successful and well received presentation I have ever done. The reason? After ripping the thing to pieces I then demonstrated a revised version of the product with a more well thought-out UI that addressed the issues customers had.

Always sweeten the bad news somehow, or people can REALLY resent it - which defeats the object of the whole exercise, since they are far less likely to go along with change if they do.

Good ideas.  I've mellowed and altered my approach with some of the input.

I will show examples of the one way (yes, it works) and another way (look, this is better). And the other way will always be a developer who is currently working. The problem is really with the people who are not developers. I won't point any fingers. In fact I'll try and always an instance of some of my work and show before/after.

Perhaps then through the introduction of some basic concepts there might be some recognition that how code is developed is important.

In my experience, one of the best ways to do this is to get one or two developers bought into the following key idea:

"Whenever you touch a part of the system, leave it slightly better than when you arrived".

This way you aren't too tempted by the "just throw it all out and start again" desire that many of us suffer from, and the system DOES get better. 

Managers (especially non-technical) really don't care about your points. Unless you already have a very good rapport with the managers your presentation idea is likely to fail both to persuade anyone to do anything different and to enhance your standing in the company.

Most managers are worried about issues from a business point of view (which includes the cost of rewriting versus delivery to market) and unless you can communicate with them using their language you are likely to struggle massively.

The way you are writing on this forum seems to suggest that you may not be able to do this. I recommend you don't do the presentation and do the guerilla action instead.

I just wouldn't embark on such a voyage. It can only end in disaster. YMMV.

It sounds to me like you've put too much thought into the technical problems, and not enough thought into the people problems.

You say you've been finding SQL injection vulnerabilities. Okay, that's easy to fix technically - patch a change, or submit a bug, or whatever the process is. But solving the people problem that led to that vulnerability is a completely different issue requiring a completely different solution.

The problem is, it sounds like your solution is "I'm going to teach the guy who left the vulnerability why and how not to leave vulnerabilities." It's a noble approach, but what a lot of people here are saying is, it may not be workable.



FWIW, I agree with the suggestion to find executive sponsorship. Showing a VP that you can delete records without logging in is going to be a bigger motivator for change than showing your colleagues a presentation on topics they think they already know.

I agree with the comments on sponsorship. You need to have the backing of *someone*.

Also, what problems are being caused to the bottom line of the business itself by current practices, and how do you propose to solve those problems in a way that will provide a real and quantifiable difference to the bottom line of the company?

If you can't answer that clearly then you're "wrong" in terms of the needs of the business no matter how right you might be in terms of good programming practice. And outside of a company whose business is writing and selling software, or an academic computer science department, I'm really sorry but that means you're wrong, period.