Putting Code Together Since 1987

Posts Tagged ‘development’

What Used to be Hard, Becomes Easy

In Web Development on June 10, 2008 at 11:20 am

One thing we talk a lot about is how important it is, for costs, to stick to problems which have already been solved. Get fancy and do something new, and your costs have rocketed away.

A developer has just done a nice little piece on spellchecking. In 1984 it was ferociously hard. In fact, if you wanted a decent spellchecker in your custom application you had to pay dearly for the priviledge. Today it can be accomplished in a few lines of code.

It means that what was once going to cost you £100k to add to an application is now a few pounds.

Similarly, when we develop we offer up lots of wonderful functionality at incredibly low cost, because we’re just pulling in something that’s already been done. But if someone asks us for something custom, the price leaps up. They don’t always get it.

So here’s how we do it:

Step 1

We don’t know if the problem’s been solved before, and we don’t know how long it’ll take us to solve it either, so we give what may be considered to be evasive responses. We need time to research. Someone has to pay for that. Depending how interesting this research is to our business model, we may subsidise it. Otherwise, the client pays.

Step 2

If we find the problem’s already been solved, we still need to test the solution to make sure it applies well to the client’s requirements.

Step 3

If all is well, and the solution is found quickly, the client gets a call to say “yup, no problem, it’ll take us x amount of hours.”

But if we found no solution, we have to estimate how long it’ll take to develop the solution. And that’s hard in a commercial sphere. People don’t expect to spend much on R&D – they just want solutions.

So we do spend a lot of time trying to get people to understand the difference between solutions, and development. Just like a DVD player is a £30 piece of kit if you buy one from Sanyo while it would cost millions if you tried to make one your own from first principles. It shocks folk, but it’s an important message to get across that all developers need to take on board and to pass on to clients, or they end up stressed and trying to do the impossible on very low budgets.

How Much Does Code Cost?

In Web Development on June 1, 2008 at 3:56 pm

It’s hard to measure the cost of code.  Simple stuff can be ferociously time-consuming to develop, and bad coders often produce reams of poorly structured code.

But let’s assume you’re dealing with a typical, decent developer who doesn’t take the long route, or dangerous shortcuts.

There’s some nice research covering this, such as Boem, Abts Chulani [2000] which is worth reading if you’re interested by this kind of stuff.  But it’s heavy going, and doesn’t give a nice neat figure for lay people to understand.

So now I’m going to give the answer that many want to hear:

For each line of code produced in a 3GL non RAD environment the cost of your development is likely to come to around £20-£25 per line of new code.  And about £100 per hundred lines of re-used code.

Doesn’t sound too bad… that includes testing, development, refinement, code reviews and so on.  It’s based on the idea that most good developers can produce around 50-100 lines of code in a day if left alone and in peace.  Some produce reams of code, but it’s often poorly optimised and thought out and likely to bite back in years to come.  The cost also takes into account the design of that code before anyone touched a computer, and the various support staff required.  If a developer is working entirely alone and is self-supported with his PCs and the like, then his productivity drops so the project takes longer, but the cost shouldn’t change too much.

And don’t forget that cheap code is often bulkier than expensive code.  Which means nobody can look at a 1000 line program and actually say “Oh yeah, that’s £20k’s worth.”  Somebody needs to assess the quality of that code.

What we will say is that in general, if we’ve written you 1000 lines of fresh code (ie, no cut and pasting or reuse) it could well have cost you £25k by the time it’s fully tested and delivered.  A really big project, like, say, implementing a worldwide global payroll system for a major corporation may have five million lines of code and a final bill (including analysis) of around £125 million.  Not at all unreasonable, believe it or not.

So yes, code is expensive.  And that quick report you’d like us to knock up?  Maybe it’s not so quick.

To save costs it’s worthwhile looking at RAD (Rapid Application Development) methods, but in that you’ll end up with slower, more bloated code.  However, it can be a perfectly adequate approach and we use it all the time for simple data management back-ends and the like where performance isn’t that critical.  Sometimes we’ll generate 20,000 lines of code from a three hour job… but it gets the job done.  Albeit a little slowly!

Coming Problems with Web Design

In Design, Web Design, Web Development, Wordpress on February 23, 2008 at 2:34 pm

I just read an interesting article in A List Apart about how browsers that are forgiving of bad markup and css are bad for the web.

And I totally get it.

In fact, a failure of how standards apply to web pages is one of the reasons why, until really quite recently, I’d avoided having anything to do with Web Design. I hated it. I hated that even if you structured your code correctly it would look right only in half the browsers you tested in.

Well, this is going to change over the coming five years. Standards will become far more important, and odd hacks will slowly fade into the background. Browsers, my friends, are going to have to become a whole lot less forgiving.

And there lies the rub – with tougher browsers, building websites will become a lot harder for non-technical types. In fact, it could become near impossible. On the upside, tools like WordPress will be able to offer more choices to the user because the code will know that what it outputs to the browser will work.

So the internet’s going to get a lot better in the coming years… but if you’re not prepared to work hard at it then becoming a web developer or designer is going to become far tougher.

Safer Passwords & Using PasswordMaker

In Web Development on February 7, 2008 at 5:53 pm

You may find passwords to be an unecessary chore. But they’re important. However, inventing strong passwords is difficult… and they’re hard to remember.

So you need to be able to generate passwords on the go.
Go see Password Maker – a great way to have safe, difficult to crack passwords which works beautifully as browser plugins.

The nice thing is that if one password is found out because of a compromised website, because PasswordMaker generates a different password for each site, you’re still secure everywhere else. Of course, if someone finds out your master password and works out what your encryption settings are and knows that you’re using such a system then they can get in to everything. But you’re not that careless are you?

You may want to reduce down the characters in use for passwords a little so that you don’t get characters that many sites don’t like – for example, WordPress doesn’t like slashes.

Make a note of the exact character set, encryption method, lengths and so on. You may need these at some point. However, without the master password, this information is of limited use, and you don’t have to write it in a way that can be understood by anyone else but you.

Make a habit of using this system wherever possible. You’ll find life a lot easier, and more secure, if you use it consistently.

Bug Tracking

In Web Development on January 11, 2008 at 6:26 pm

Want to know how we keep track of all those websites and bugs?

It’s quite simple – we use Mantis Bug Tracker.   It’s not as powerful as some, but we’re a three man company – a more heavy solution would probably simply be going over the top with things and would carry a support load that we simply wouldn’t be happy with.

In other words, it’s a great fit for our needs and requirements today, and for the next few years.

The Wicked Problem

In Design, Web Development on January 10, 2008 at 5:41 pm

I was reading through some project management methodology just now (yay! My life is full of joy at last!) and came across the phrase “The Wicked Problem” in this line on Wikipedia:

Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a “wicked problem” – a problem whose requirements and limitations cannot be entirely known before completion. The implication is that it is impossible to get one phase of software development “perfected” before time is spent in “reconnaissance” working out exactly where and what the big problems are.

It’s worth following the link.

I think software and design processes often end up trapped within this circle where nothing’s ever perfect. The iPhone isn’t perfect, for example – it may be ever so pretty, but it’s quite rubbish at Bluetooth connectivity, for example, or sending texts. In fact, it’s rubbish at a lot of things. One of its smartphone rivals, the N95, has a habit of crashing in certain situations, and flattening its battery in two hours because it’s furiously running an application in the background.

Same with websites. Our company site, Interconnect IT, will never ever, in my opinion, be perfect. Unless we simply devoted all our energies to that site – but then we’d have no time to working on client projects. We’re still a three man company, so we can’t have a £200k site. But we can be clever and cover 95% of the requirements.

With client sites it’s even trickier – we have to interpret a clients’ requirements, write them down, and send them back in a proposal with a rough mock-up, pricing and structure. They’ll read it quickly and usually accept. But once started they’ll look at the design, try it out, and realise that actually, the front page should have a simpler message. That may mean a restructuring. A week later, someone may point out that the colours they preferred have negative connotations in certain cultures.

All these require changes, sometimes at a late stage, and sometimes involving a lot of work. At some point, someone has to simply say – “OK, that’s good enough!”

Other clients, however, quite like the waterfall method. We have forms for certain business sectors, with consistent requirements, where they simply tick off what they want and like, choose an off-the-shelf design, and a couple of weeks later we deliver the website – all loaded up and everything. They then sign-off, or they ask for some revisions – images changed, copy edited and so on. It’s particularly suited where a small and busy firm needs a website, but it’s not really crucial to their business – it simply provides a service to people who already know them. Dentists, for example.

Site Features Can Go Hilariously Wrong

In Web Development on December 19, 2007 at 12:45 pm

I’m going to shamelessly nick a few images here from a site we designed, manage and host (Sniff Petrol) , but which is run and written by someone else. In finding this he showed a great example of why you should think about any new features you add to a website.

The idea seemed good enough – Car Magazine added a search terms Cloud, rather like a tag cloud, to their website to show what people were searching for. Problem is though, with any user generated content you have to watch carefully for abuse.

First off, they seeded the search cloud with a few terms that they obviously felt the aspirational and tasteful visitors would like – such as Aston Martin Vanquish, BMW M1, Ferrari and so on:

Car Magazine 1

So far so good.

But Sao Penza? Who would look for such an obscure car? Quickly, somebody realised that there weren’t many values for the search cloud to pick up on and that it could easily be gamed… Either that or readers of Car Magazine have a hankering for Bum Gravy and Cillit Bang:

Car Magazine

Perhaps it was just a passing glitch and soon everything would return to normal:

Car Magazine 2

Ah, no… and guess what? The took it down soon after.

I think in any sort of web development and design it’s important to try and think “how could this be abused” and then either put in place ways to prevent it, or be ready for it. Some sites have disappeared completely after being spammed to death, with the owners unable to fix it, and lacking the funds to bring in suitable expertise. It’s a hard world, the Web, and coding safely for it demands a rather cynical approach at times.

All stuff taken from this Sniff Petrol article, and written in a much funnier way than I can ever manage…