Sometimes during software development you need to hack something together temporarily just to see it working. You have no intention of leaving it like that.
We recently needed to add an email field to something we’re working on. And to make sure we didn’t forget about it we made it ridiculous.
Now it works, but we can also tell it’s not finished. And we can have a laugh about it.
There are other techniques too. You could set up a CSS class called “temporary” that throws a ugly thick purple border around things you know are temporary.
Or you could just keep a log somewhere, but we think it’s better to show the temporariness on the screen itself instead of on a piece of paper that may or may not be accurate and comprehensive.
What techniques have you used to keep ugly temporarily-necessary hacks from slipping into your final release?
Ryan Guill
on 07 Dec 06I develop primarily in eclipse, and with the right plugin, you can put a comment in your code with TODO: at the beginning. This puts the comments in a todo view that we always check before release. But we do things like your example as well, things that are obviously not right, so if it gets to QA before we catch it, we know we will hear it from them!
Marc Hedlund
on 07 Dec 06We also put comments in code, FIXME and REVIEW, and Coda just put together something that emails them to everyone every day.
Like Jason’s purple border suggestion, we’ve found transparency to be the biggest aid to quality.
Jacob Patton
on 07 Dec 06When I’m coding an app, I give unfinished elements a .todo class so that I can run through the app in the browser and quickly see where the UI needs work. (It also makes it easy to do a global search for these items in the text editor.)
Incidentally, I also use a .docs class for developer documentation. It works the same way as the .todo class does, but it lets the developers highlight comments in the working app and turn them off (via the CSS property display: none;) to see the app cruft-free.
Of course, with both of these techniques, you have to be sure to delete the extra classes and docs before releasing the app!
Dylan Bennett
on 07 Dec 06I know it’s not for web, but in the application development front…
The “Napkin Look and Feel” UI interface for Java is excellent for this type of thing. It makes the UI elements of your app look like they were drawn on a napkin—but they are totally functional! It’s great for prototypes where the client always assumes that what they are seeing is a working application when it’s really just a UI mockup.
You have to see the screenshots to really appreciate it.
Sort of reminds me of the cool game Kottke posted recently where the whole game looks drawn on graph paper.
Daniel Burka
on 07 Dec 06In CSS files, I specifically use a real-world color value for temporary stuff. Using “purple” makes it really easy to see things visually and even easier to search for in the CSS file itself.
Eloy Anzola
on 07 Dec 06I leave comments in code. But they can be easily ignored.
If I left crazy text, or ugly purple borders, that would be the first thing that I would hear from the sales & business teams.
Besides, sometimes prototypes are demo’d to prospects, so we want them to look ok.
So, I place a fairly obvious box, usually at the bottom, sometimes at the top of the page. Like so: Example Box
David Demaree
on 07 Dec 06I use a lot of lorem ipsum dummy text, so that’s usually a giveaway. However, my preferred way of absotively posilutely denoting something as ‘TEMP’ is to give it a horrible magenta background (hex code #f0f). Very, very hard to miss.
Brian Sweeting
on 07 Dec 06We use the bottom of each screen as a notes area where we can document everything that is not clearly evident in a static html/css prototype. We also use a class like “deleteme” that allows us to put temporary notes in-line with a red dotted border around them so it is clear that they are to be deleted in the live product. We also added some javascript that allows us to hide these elements (notes and in-line) notes, so we can see the screen without all of the temporary junk.
Peter
on 07 Dec 06Yeah…. Prevented temp stuff from making it to the real site… Well I… usually… LOOK OVER THERE! (whoosh)
Havagan
on 07 Dec 06I use the “TODO” keyword in my comments. When using Visual Studio any comment beginning with “TODO” will show a message in the IDE letting you know you still have tasks to perform. There are additional built-in comment keywords like “HACK” and “UNDONE” and you can add your own—you can even set the priority so that you know which items to address first.
Eddie
on 07 Dec 06It’s no knock on the process, but inevitably something will get overlooked by poor testing etc… only to be found by the customer.
How about a pop-up or alert or some kind of event trigger… that (because of poor testing) never gets exercised until it ships.
I think we’ve all seen some kind of alert message that is overly nonsensical… Sometimes it’s borderline if the programmer intended it or not (to be funny?)
Jameson
on 07 Dec 06Post about the temporary element on the project’s development blog—worst case, a hundred alert users will e-mail you if you accidentally leave it in for the release.
Alexander Graf
on 07 Dec 06I use a .temp or .todo class with a border: 2px sold #F0F; which i put in a separate imported CSS file. So, if I have to do a presentation, i can just throw the import away and everything looks fine. But your “like for realz” is pure class :D
Forrest
on 07 Dec 06For anything I am working on within a webpage I will usually set the background-color: lightblue to indicate temporariness. This is both non-ugly and noticeable enough that it reminds me to remove it later.
Adam Thody
on 07 Dec 06I’m also a fan of using a temporary class to highlight elements which need attention.
I also generally have a class which I’ll assign to copy that needs work, or needs to be written (red bg, white text). It’s amazing long test copy can last sometimes without being noticed, and this makes it impossible to miss.
John Topley
on 07 Dec 06Didn’t p addy change his name to p diddy? ;-)
Andy Kant
on 07 Dec 06I usually put “FIX: ” in a comment in the code or record it as a “to do” in a text document (or both). I prefer to record it in a separate list though, its too easy to forget something buried in thousands of lines of code.
Raghu Srinivasan
on 07 Dec 06For maximum annoyance I use something like a (script)alert(“Hi ” + some message abt what needs doing )(/script). It will eventually annoy you enough that you will fix it.
Phil
on 07 Dec 06You gotta be careful as Eddie said. This stuff ends up accidentally in production one way or another. If you need to name something to ensure it’s tested before being released, theres a good chance your testing processes will overlook this kind of thing entirely.
Kevin Holesh
on 07 Dec 06I try to keep my cruft as simple as possible. I just add a ### wherever there is something that needs looked after. If I need to, I can just do a quick text search for the ### thing and viola. Piece of cake…
I’ve found that adding a css class or a javascript event to something is just too complicated for me. Plus the ### works in stuff that isn’t for the internet too, like your writing.
tamimat
on 07 Dec 06I realized that using these jokes may end in problems if you start to use the real content.
Nathaniel
on 07 Dec 06That’s interesting; I recently started doing the same thing. I think I called my css class “unfinished.”, and it makes the background color red.
I find applying it to links that lead to non-existent content useful too. It makes it easier to find things that still need doing.
shane becker
on 07 Dec 06Code i want to come back to I WRITE IN ALL CAPS, because it’s ugly and will remind me to revisit it.
Chris Busse
on 07 Dec 06I prepend things (comments usually, sometimes variables) with “xx-”
That makes them easy to see when scanning the code, and easy to find because that string isn’t likely to be used for anything real.
Doeke Zanstra
on 07 Dec 06On the HTML element, I add as class-name the name of the domain the pages are served. I use this technique mainly to distinguish between test and live site. To make me remember at all times (it’s very easy to insert data on the wrong one), I have the following CSS:
html body { border: 5px solid yellow } html.zanstra\.com body { border: 0 }
Court
on 07 Dec 06re: Phil’s comment, case in point:
This technique can work in a small outfit, but i worked in a large engineering house and used silly strings on some experiments, and they got wrapped up and sent for publishing. My performance review dropped a bit that year.
entering in a comment and then doing a mass search is the method i use now for things that i need to get back to.
TJ
on 07 Dec 06.todo { background: yellow; color: red; }
Graphic designers love me for this.
Ben
on 08 Dec 06Personally, I log it in the database, then run a task to find all hacks once the site is almost live. After that, a cron is run so emails will be sent every hour until it is addressed. Very annoying.
Tom
on 08 Dec 06On one recent project, I used the foo action to do this. The link explains it, but in a nutshell: link dummy code to a static page that says “the developers know this isn’t finished and are working on it”. That way, all the stuff that actually fails is stuff the developers have forgotten about. It improves the quality of feedback whilst making sure people know we’re working on stuff.
jetrac
on 08 Dec 06I’ve learned the hard-ish way to only use text and comments and class names that I’d be willing to have a humorless project funder see. My ex-boss once didn’t get that the dummy text we had on the page meant it should NOT be seen by anyone outside the org and sent it around to a bunch of people to see. I was mortified.
clifyt
on 08 Dec 06I too learned this the hardway.
A former developer working for me was extremely literal. He asked me how to do something, and I was sick of doing his work for him everytime, so I though I’d at least make him edit the code to remove my smartass comments.
During a live demo with stakeholders, I let them take over and play for a bit and we hit an error. Unfortunately, the error message was never changed from “If you are getting this error, you are an eff’in idiot blah blah blah” (it just got worse from there and very insulting about person that created the condition that caused the error).
The other team wasn’t happy, and the developer didn’t blink an eye. When I apologized for it and said it was never intended to be in the app, the developer states in a monotone that, no, it was supposed to be there because its exactly what I told him to do.
He was reassigned after that to less sensitive tasks…
victor
on 08 Dec 06now that i read this post:
“i use blatantly ridicule, obviously-this-is-not-for-release text, and 2px solid magenta borders”
why?
Peter Cooper
on 08 Dec 06Just use a nice CSS class that does some pink highlighting (or whatever clashes most with your color scheme). It’s easy to turn on and off, and gives you something to search for with your text editors.
Putting silly text in can bite you in larger teams if things get pushed out without everyone knowing ;-)
Gustavo
on 08 Dec 06I have a friend who named the CSS classes after zoo animals. I lost count of the amount of times he forgot and left them in!
Mark M
on 08 Dec 06I’m a technical writer, and I bracket text with double question marks.
It’s fast and easy to do, it stands out on a printed page, its meaning is obvious (check this), it’s easy to search for, and spell-check always flags the double punctuation.
So far, in seven years of using ??, unchecked temporary text has never reached a final release. The spell-check thing alone makes sure of that.
Danny Hope
on 08 Dec 06We use 2 Techniques.
Keith McDonnell
on 08 Dec 06Glad you asked! Here’s how we handle intermediate code.
Insert a meaningful comment, such as (in html code):
<!- TODO: remove this ugly hack ->
At a later date, search for all TODO comments in your source tree:
$ find ${APP} -name “.” | xargs grep ‘TODO:’
Then fix’em—no broken (or dirty) windows!
We use subversion, so unfortunately you get two results for each source file.
Does anyone know how to ignore the .svn dirs ?
Keith McDonnell
on 08 Dec 06Hmmm …
It seems my text has been altered/mangled in the above post …
The name switch for the find command should read:
-name “star dot star”
Stupid blog post formatting :)
Brad Fults
on 08 Dec 06or…
function get_ridiculous_pagination($base_url = ’/’, $result_set = null, &$search_args) { ... }
Keith
on 08 Dec 06Someone lost their job at the local newspaper here for doing the same thing with an article on a local priest… and then neglecting to take the word “Nazi” out of the headline before it went to press. I guess the moral of the story is: be ridiculous (we all love to do it, don’t we?), but know when to put a cap on it.
Charlie Park
on 08 Dec 06Like Daniel Burka (above), I use real-world color names in production, usually as an in-line style (which I remove before launch), and usually as a color that I never use in my design (“pink”). This is primarily when I’m playing with divs and seeing how they relate to one another, what their widths are, etc.
dirk lüsebrink
on 09 Dec 06besides the usual FIXME and TODOs in the code i found it realy usfull to intentionally leave syntactically broken code in the source files at the place i got to interrupt development for a night break. coming back later makes the compilation step remind you exactly where you have to pick up work. This works best for compiled languages of course, nowerdays i basically do ruby almost entirely. long gone are the C++ days…
have fun
Lea de Groot
on 10 Dec 06body#developmentserver.com .todo { background-color: yellow; color: red; border: thick solid purple; }
and the body id is programmatically generated to match the current domain :)
Then all we do is drop a ‘class=”todo”’ on anything that needs work. Can’t make it to production, can’t be missed in dev :)
Ansel
on 13 Dec 06Put it in the bug tracker as a blocker for your next release. (You DO have a bug tracker, right?) Then make sure you clean up your blocking bugs before releasing anything.
This discussion is closed.