Less vs Simple

We had a discussion the other day about whether simple is better than less. I always believe that the simpler the code, the better. To write simple code is a glorious thing. You will be praised by your successors and revered for understanding the tenets of good coding. Your peers will respect you and girls will find you attractive. Well, maybe not the girl bit, but the others will follow.

What are the tenets of good coding? (I reserve the right to change and reprioritise, based upon my current beliefs) :
1. Avoid duplication
2. Write testable functions
3. Aim for Simplicity
4. Reduce the cost of change

Now each one of these is a complete post in itself. And they require quite a bit of discussion for the intent of the statement is understood. I believe that to truly understand these guidelines you mush be switched on. The catch is that the switch is different for everyone.

A while ago I posted about an epiphany that I had. That was referring to the understanding just how important unit tests really are. It was one simple statement that a peer had said that stopped me in my tracks. I just got it. There were even more benefits than I realised at the time and further research and experience has taught me those.

From then on I always feel exposed when I'm writing functions that are not the subject of unit tests. Actually, the discussion of unit test is worthy of a complete other post as well. And covered under tenet #2.

Now you're looking for the meaty bit - the examples. Well, I'll get to those, but for now this is just something that I had to say to start the process. Soon, I'll post more on each of these topics and more.

Believe me when I say that I'm opinionated...

Oh, and if you're wondering if we won the Grand Final, mentioned in the last post, then yes we did.

stuff and things

Haven't posted in a while, so I'll combine a few things in this one...

I went to the launch party tonight for VS 2005. I met a few people and can now put bodies to blogs. Frank, I'm impressed that you knew the name of my blog! I, along with Eddie and Geoff "won" copies of VS2005, SQL Server 2005 and Biztalk Server 2006. w00t! (although I don't really know what that means)

I bought Paul Mac's latest album "Panic Room" recently - it's really good. If you liked his first one, then I wholly recommend that you get it.

We had a major release last night. After a long time in development and a change in management, we got it out and apart from a few small issues, it all went well. This is part of the reason that I haven't posted in a while...

I play in an indoor cricket team on Tuesday nights. We're called "Warwick Todd VIII". We won the game last night and are now into the grand final next week. Hope we win.

We have been playing on and off (but mostly on) for about 10 years now. No, that doesn't mean that we're any good. I think that we're going to call our team "Preston's Brothers Brand" next season. I could explain it to you, but trust me you don't want to know.

I've also read a few more books recently, One Minute Manager, Fish! and am half way through Refactoring to Patterns.

Reviews:
One Minute Manager - An easy read and seems to (mostly) make sense. It was originally written in the late '70s, and the reprimand concept using emotions seems a bit dated. But what do I know. Although I agree completely with the praise and goal definition concepts.

Fish! - Nice story, but I don't think that it's that simple. Also an easy read.

Refactoring to Patterns - Very dry in places. Which is a pity. There are some great patterns in this book. The author has a great respect for Martin Fowler. I just wish he'd used his or Kent Beck's writing style. Those guys were much easier to read.

bit late, but still

I have finished Test Driven Development: By Example. This is a very good book about TDD. I highly recommend that you read this one if you're interested in TDD.

rebel without a clue?

I used to not want to be a geek. I wouldn't read technical books, nor technical websites. I played with computers after work, but it was just that, playing.

A little while ago, probably about the time when I started this blog, I decided that I could ignore it no longer. So I got hold of some books and started reading. And reading blogs and accepting that to be better at my job that I need to improve.

So, I've read about 6 books since then and have a stack on my shelf of about 6 more. Then I'll be onto amazon to get some more.

Why am I telling you this? Well, because I discovered just how easy and important it is to do this.

I'm realising that in the last 12 months I've learned so much and found proof that some of my crazy ideas weren't crazy. In fact, they were pretty good *blows on nails and polishes on shirt* ;)

If only I'd started this earlier...

bam! one more

I have just finished "eXtreme .NET - introducing eXtreme programming techniques to .NET developers" by Dr Neil Roodyn.

It's quite a good introduction into the art of agile project methodologies.

and another one down

I've just finished reading "Object Thinking" by David West. Quite an interesting read. He proposes that the true intent of OO has been misinterpreted by many and that the true path will set you free...

If anyone else has read it, I'd love a chat about it.

another one down...

I just finished reading "Effective C#: 50 specific ways to improve your C#" by Bill Wagner. Definitely worth a read. Not too long, and each point is only several pages so you can just read a bit and put it away, read a bit and put it away, read a bit, and - you get the picture.

I've started Refactoring by Martin Fowler. Seems like another great book.

I really wish I'd started reading these much earlier in my career. Although I'm finding that a lot of what I'm reading I'd already picked up from other sources, but it's nice to read a comprehensive coverage of each topic.

more is more

We've recently had seven people join our team. We recently only had 5 full time developers in our team, so that's a big increase (sure, I could have worked it out as a percentage, but you can do that in your spare time).

The change has been great, I always like meeting new developers to get their perspective on how they approach their work.

It also gives us the chance to do stuff we've been too busy to do - like more pair programming.

Welcome to Richard, Michael, David, Kyle, Mark, Goran and Andrew.

less is more...

I've been reading/watching/thinking about this recently. Everyone's saying less code is better and I agree. The less code, the less chance for bugs, the less the program has to do and the less code paths makes the code more robust.

Now the art of writing less code is easy - understand exactly what is required and implement it the simplest way possible. Also, avoid duplication of code or functionality like the plague and you're on the way.

Get on board and write less!

swimming upstream

Anyone with experience (or knowledge, Mitch ) will know that the more time you spend on upstream tasks will pay large dividends further into the product cycle.

I know there's no easily identifiable point when you know you've done enough analysis and design, but it's better to overspend in this area then suffer the consequences later.

It's amazing how just one extra class or one decision can save hours (or weeks!) of work.

You're never going to get it completely right, as the details are never immediately obvious. But that's no excuse not to try.


Right now, I'm doing a bit of swimming upstream...

Object Orientated Design (OOD).

OK, I am a big fan of OOD. Why? Well, it makes your life easier. Yes, it can be a bit harder to understand and grasp what's actually going on, but the payoffs are immense. Once you get into the concepts, you really see how it's just logical.

If you want to know more, read http://blog.objectmentor.com/ArticleS.UncleBob.PrinciplesOfObjectOrientedDesign

Please.

Epiphany

Epiphany: the comprehension of the meaning of something through a sudden intuitive realization.

Had one just the other day.

It's strange. You read something and go "yeah, that's good." And you acknowledge that it's something that you "should" do, but you don't.

And then, some time later, you're discussing it with someone else, thinking about it in the shower or the realization just pops into your head from your subconscious. And you just suddenly get it. A total and utter understanding of WHY you should do it.

Wow.

best book ever

No, I'm not going to tell you that the best book ever is "The Davinci Code". It's good, but not that good.

What I am going to say is that the best book ever is "Code Complete 2" by Steve McConnell. If you're a developer (or even just someone involved in the whole IT industry), then please, do yourself a favour and read this book.

'Nuff Said.

Process, Process, Process

Sorry. I should have made this more obvious in my last post. I do think that process is important. Very important. I would have to say that I prefer Agile type processes to waterfall for a few reasons:
- it helps you identify progress and problems early and frequently
- it accepts what IS going to happen and embraces it (i.e. iterations)
- more team focused and skilling orientated.

That's not to say that you can't do all that in a waterfall project. Infact, I bet that the waterfall projects that are classified as successfull actually implemented those points, but not in a formal fashion.

wondering

There's so much talk around at the moment about how many projects are failing and the quality of the result when they do succeed.

The main thing that industry experts suggest is that the issue is the process. I.E. Waterfall projects tend to fail and XP projects do not.

Hmmm.....

salt and vinegar chips

Seems there's a new player in the almost full to bursting point salt and vinegar chips market. Arnott's have been advertising their "Tasty Jacks". They say that if you try them you'll never go back.

Well I did, and although they're pretty good, I'd say that they come in at #3 on my list. So what's my list? Glad you asked:

#1: Kettle Sea Salt and Basalmic Vinegar. Fantastic!
#2: Smiths Salt and Vinegar crisps. The thin slices really add to the enjoyment
#3: Arnotts Tasty Jacks Salt and Vinegar. Great attempt, but can't quite match the taste of #1 or #2.
#4: Smiths ridged Salt and Vinegar. Good regular chips.
#5: Pringles Salt and Vinegar. Ok.
#6: any other brand. No one really cares at this level.

I also have very fond memories of a chip called the BIG Salt and Vinegar. I think that they were only available in about 1985. Probably because the flavour was so strong and the chip so thick that several children were admitted to hospital with salt and vinegar flavour poisoning.

Anyway...

testing...

I used to always feel ashamed that I'd missed something when the testers came back with issues. I have now changed my mind.

Testers are experts in their area and I'm an expert in mine (I hope!). It's their role to check everything to ensure quality. Besides I should spent less (yes, less*) time testing and more time coding. I should not try to write code that will pass all possible tests (functionality, uat, random, etc) in the first instance. Almost all apps will fail testing to some degree in the first run. Why not accept this and move onto a smaller and more frequent develop/test cycle?

So now, I'm happy that the testers find things. It means that they're doing their job and I'm doing mine.

* Less time, but more effectively.

am I geek enough?

It's strange. I'm kind of in between being a full geek and not quite. I really like what I do and technology and stuff, but most nights I still like to sit in front of the telly and do absolutely nothing.

The guys I know who I would classify as Fully Geek (and that's a compliment) seem to spend every available moment researching something technically cool whether related to their employment or not.

I guess I haven't got what it takes to be Fully Geek. Maybe I could be just Mostly Geek...