Risk Factory - by kyz - flickr.com Creative Commons
I’m interested to hear feedback regarding how other development companies measure project risk.
We currently track three general classes of risk (although in a very simplistic way) for a project:
1) Technical risk – how likely is it that we will run into something that we don’t know how to solve (or that can’t be solved as stated – or is generally insoluble).
2) Bottom line risk – how likely is it that the project will cost too much to build (i.e. it won’t be profitable). Note that even projects that are not fixed cost (i.e. are billed on an hourly or some other type of flexible basis) can run into issues if they start to cost more than some unstated budget on the customer’s end. This type of risk is frequently the largest concern on our end of things, because (like many service organizations) our largest expense is staffing.
3) Customer risk – I’ve had customers go out of business, vanish, fire us etc in the past. There are frequently warning signs from the start that a particular customer may be more risky than usual. We’ve started tracking issues in a database to try to become more adept at evaluating this sort of risk.
How does your company measure and evaluate risk? Are there relevant categories missing from my list (VaR, Black Scholes etc aren’t really relevant to software development – I think).
I did something completely idiotic this afternoon.
While assisting one of my staff with a problematic installation of some open source software on a server, I decided to clean up certain files that we no longer needed with “rm -r *”.
Only to discover that I was in the wrong directory.
It didn’t help that we had been working directly on that computer for several days.
I was saved from losing a week’s work only by the fact that the backup from the morning was good (you never know with backups). We still lost a few hours of work, but that’s much better than it could have been.
Moral of the story: a) backup even more regularly than you think necessary, b) keep a local copy of your working files, c) don’t use “rm -r *” unless you’ve double checked what it will do.
Image courtesy of "gutter" on Flickr. Creative Commons.
I just spent a chunk of this afternoon fixing up a friend’s website which was hacked. The hacker appears to have gained access through a decade old shopping cart (not in use, just sitting in a folder on the site), and then proceeded to insert obfuscated javascript code into every page on the site (several hundred pages, with the code slighly different on each page).
This is the fifth or sixth site I’ve had to clean up in the past year or so, and its always a painful job – I’m pretty good at spotting code that shouldn’t be in a page, but with a large website it can be hard to be certain that it has been completely fixed. And there’s no guarantee that the original loophole that was exploited has been removed. Even under the best of circumstances, cleaning up this sort of mess is a painstaking process.
The following is intended for web designers who aren’t coders – but who use scripts that they have located on the web. Some intro level programmers might benefit. Experienced web programmers should go directly to the following link and do some review: http://cwe.mitre.org/top25/
1. Be very careful about downloading “free” scripts off the web. Do yourself a favour and scan the code before using it. If it has been obfuscated, or it looks odd, you probably want to avoid using it. You don’t need to be a programmer to get a feel for nefarious code.
2. When putting together a website that has any kind of dynamic functionality – be it javascript, a php script on the back end, or something else – bear in mind Jeremy’s Addendum to Murphy’s Law: Whatever can be hacked, will be hacked. There are a lot of common loopholes that hackers exploit that could be easily avoided by looking at code with a cynical eye and trying to figure out how it can hurt you.
3. Periodically review old websites that you’ve done. Code that used to be fine may no longer be so safe. Also, as you learn from mistakes, you may notice all kinds of things that are dangerous in your code.
4. Its also really worthwhile to look at the Top 25 Dangerous Bugs list, linked above. A periodic review is in order. Speaking of which, I’m adding that to my to do list.
5. Verify ALL inputs to a script. If you think you have verified them, get somebody with a cynical bent to test it. If something is up on the web, it is guaranteed that somebody will try some oddball and highly unexpected inputs just to see if they use your script for their own purposes.
6. Remember at the end of the day that there’s absolutely no such thing as a hacker-proof piece of software or hardware. Make regular backups. Assume you’re going to need them.
I just want to finish with an anecdote.
I used to operate a small hosting company along with some of my other duties at my former company.
One day, one of our servers started broadcasting vast volumes of spam email, to the point that we had to shut down the outgoing email service.
I spent a few hours reading log files, trying to pinpoint what exactly was happening. I finally narrowed it down to a script that had been uploaded a few days prior on one of the client’s accounts.
The script was basically a feeble attempt to try and implement a CMS (content management system). Basically the way it worked was that any GET input to the main script was assumed to be the name of an html fragment file, and was included into the script with no verification whatsoever.
If this means nothing to you, you’ve probably seen websites that have URLs something along these lines: index.php?id=123. The “id=123” part can be parsed out by the script as an input. In this case the links looked like this: index.php?page=contact.html.
The script just assumed that contact.html was a piece of HTML code, and included it in.
It didn’t take long before half the hackers in the world were sending the script stuff like this: index.php?page=path_to_malware_or_spam_script. And our server was running those bits of malware as if they were located locally.
I’m currently working on fixing a mess that somebody else made. They used all the right tools (Zend, MVC pattern etc) but then proceeded to make every possible mistake. In any given situation where a design decision was needed, they made the wrong choice.
The specific issue I’m dealing with is that I need to replace the look of the website with a new “template”. Unfortunately, the original developers didn’t stick to the MVC pattern – there’s presentation layer code in the controllers, and controller code in the html fragment files. Ugly.
So here’s the informal poll:
Struggle on, through wind, snow and hail, until the destination is achieved.
Toss the whole thing in the garbage heap and start anew.
Hire an international hitman to address the culprits directly.
Run, screaming.
I think I already know what Sol is going to say.
Disclaimer: For those without humour: the third option is intended to be mildly funny, somewhat sarcastic, and not even slightly realistic.
