The idea came to light about 6 ~ 8 months ago. Speaking to ‘Insanity’, he suggested – nay, encouraged – to write up a full outline of the what, when and how.

• What does the program do.
• When does it do it.
• How does it do it.

Or, otherwise known as a Functional Specification and a Technical Specification.

In researching ‘guides’, Joel Spolsky – famous for his various books and his site Joel on Software, I found this guide on Functional Specifications.
There are four parts to it, and I highly encoursage reading. It’s definitely helped me kick start my write up.

No longer are we required to think innovatively to solve problems – we’ve become relient on machines to work it out for us. A classic example was in a historic show I watched a few years back.

Their goal was to try replicate how the Ancient Romans built a huge Dock that went out into a harbour. The difficulty was in creating a machine to place these huge pillars into the water, hammering them down somehow at the right angle, then building the supports and planks on top, move the machine out, rinse-repeat.
These days they’d just use cranes or something to that effect. But the historical team had to resort to innovation- using only materials found in that time period. They worked it out in the end, but it did demonstrate how much our thinking had changed, and our relience on machines became evident.

Things in the Techno World aren’t much different these days. It seems that ‘Hardware is cheap’ = ‘rough enough is good enough’. In a recent Security Now Podcast (185a) the presenters were talking about how in the early days of computing, memory was expensive. They’d constantly be trying to re-write their code to make it leaner and more effecient.
Window’s Vista is a good example of modern day thinking: Just throw more resources at it, it’ll be fine.

Another area that will be spurred on due to recent economic issues is the games industry. No longer can they just turn out ‘crap’, it seems they’ll be focussing on creating more ‘quality’ products, less in ‘quantity’.
I’ve not been much of a gamer in recent years, largely because I didnt feel any of the games looked or felt any different to what’s become the ‘norm’. Even Mirrors Edge was quite disappointing: A case of interesting idea, and good design, but limitations in gameplay, and a story line which weakens as the game continues, leaves you feeling “Why did I bother?”. They couldn’t do that 15- 20 years ago. They had to develop games that would generate continued interest for continued revenue.

Perhaps its nostalgic of me, but I really do believe that things were better in the past. Largely because people have just become lazy and, well, complacent.

Rather, coding standards.
These are important to ensure others can come along, be able to read and interpret your code, and make changes / modifications – as needed.

I’m no pro. In fact, I’m still very early in my tertiary education – however already I encounted a bit of a ‘dilemma’ in coding standards.

Comments – always needed. Really. Although tedious, when someone comes along debugging, they can see what each part of the code does – assuming it isn’t clear from just reading the code itself.

When I first started coding Java (first few weeks), eclipse – my choice of editors – had a tendency of putting the opening brace { under the ‘head’ of the statement, with the closing brace } in line with the statement:

if (x == 9)
{

}

Then I recieved a ‘standards’ document, which told me I had to place the opening brace at the end of the statement, same line, and then the closing brace in line with the head of the statment:

if (x == 9) {

}

When I first read this, I felt that there must be something wrong. I was partially influenced by my tutorial teach who was saying he preferred the former method.
But then, after discussion with the two other contributors to this site, and my programming lab instructor, I changed my mind, realising that the later is in fact the better way; especially when looking at hundreds of lines of code. Makes it neater, and eliminated unnecessary line spacing – which is used to just have one brace on it.

The moral of the story: Standards are a good idea, and I encourage all to try find some that are used in the industry, or area, that you work. It’ll make a lot of people happy

If any of you are not familiar with Joel on Software and you’re a programmer, or are thinking about programming, or are involved in programming, or in any way work with a programmer, you should familiarise yourself ASAP. Pretty much everything he’s ever written is gold.

My favourite article of his (find it on his site or buy his book, I’m not going to reproduce the whole thing here) regards the presentation of an un-finished product to management. The idea is that management don’t really understand how programming works (which is more true than you can ever imagine), and when you present them with an un-finished product, if the GUI is finished then they will believe and behave as if the project is finished (which is very bad for you, as a programmer). As a result, I always make sure I leave a few deliberate bugs in the GUI of anything I’m developing, right up until the product is ready to ship.

Being (mostly) internal software that I develop, and never shrink-wrapped software, this isn’t a huge deal. But what I’m also discovering is that people on the inside of the loop (i.e. other programmers) think that what I do is stupid and that I’m bringing down their standard of work. Leaving deliberate visual bugs (and my boss is included in this) is crazy talk.

My point is, don’t listen to them. Because even people ‘in the loop’ and who should know better see a finished GUI and think that the product is finished.