Software with Ross

I analyse things. I welcome comments.
Born climber #rockclimbing #indoor #edinburgh #alienrock #overhang (at alien rock)

Born climber #rockclimbing #indoor #edinburgh #alienrock #overhang (at alien rock)

The developers at my place of work frown heavily upon ternary if statements.  I’m going to try slip this one past with some trickery…

The developers at my place of work frown heavily upon ternary if statements.  I’m going to try slip this one past with some trickery…

Programmer humour. #cleancode #java #programmer #picstitch

Programmer humour. #cleancode #java #programmer #picstitch

Brilliant piece of code from Monarch 1.7.  The developer is attempting to make sure that min is always less than max but instead disallows them being equal and throws a confusing exception (considering min can in fact be greater than than max).  Luckily this piece of code allowed me to trick Monarch into reversing an Axis.

Brilliant piece of code from Monarch 1.7.  The developer is attempting to make sure that min is always less than max but instead disallows them being equal and throws a confusing exception (considering min can in fact be greater than than max).  Luckily this piece of code allowed me to trick Monarch into reversing an Axis.

Java file reading

A neat little comparison of file read methods in Java and how efficient they are

http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly 

Try not to be accidentally vulgar when filing bugs

Try not to be accidentally vulgar when filing bugs

Blogs

 I’ve been reading a few Blogs since starting a new development position.  Mainly this is because we’ve had many discussions about how people who turn up for programming interviews generally can’t program.  

 There’s many blogs out there, some discussing quite domain specific problems faced in the programming world.  The problem there is that they generally only apply to programmers in that domain.  I find the best blogs are the ones that talk about it abstractly.  Talk about management, coding technique and procedures. More recently I’ve been reading up on better ways to get a handle on a large bulk of new code.  

So here are the blogs I find actually deal with skills that apply to all developers.  I’ll probably update this as I go, I find a new one every now and again….

http://www.codinghorror.com/blog/

http://programmers.blogoverflow.com/

SCRUM - Universally Misunderstood

Now I’m not by any means the worlds foremost expert on the design and implementation of the SCRUM methodology but let’s face it, it’s a pretty simple concept. 

  • You split your development team up into groups of 5-7
  • You split work into manageable chunks and have the team vote quickly and informally on the man hours each chunk will take and use the team average during estimation meetings (either at the start or as work arrives)
  • Every day~ you have an informal, “stand-up” meeting (each person quickly says a. what they’ve been working on, b. what they will be working on and c. if they have any blocks/problems) which should be limited to 15 minutes~.
  • Every week~ you have slightly longer sit down meetings which are slightly more in depth.
  • At the end of your specified cycle periods (e.g. 2 weeks if you have a 2 week rollout cycle) you have retrospectives (a look back) and planning meetings (a look forward).

 The point in this of course is to keep your team constantly aware what they and others are doing and understanding the project as a whole.  This has the added benefit of cutting meeting times in half as everyone already knows what’s going on.  The group estimation is a way of getting better estimates by mixing experience levels in the team. Adding more abstracted, higher level SCRUMs also has the benefit of inter-team awareness.

 The problem is that no one follows these rules.  The most recent offenders I have observed manage to fill the SCRUM skelton (as above) in a way that negates all the benefits that it provides.

 Firstly, if you turn the short, informal stand up meetings into more formal sit down meetings in which every member discusses every detail of their work then you loose a. the benefit of shorter meetings, b. the audiences attention ergo the benefit of inter-team awareness and you add c. what adds up to wasted man hours at the end of the week.

 Secondly, if you remove the estimation meetings and have senior members of the team do estimation you will frequently not meet those estimates as junior members are less familiar with the work, procedures and code.  If you have each person do their own estimation, you end up with wild, unpredictable estimates.

 Lastly, if you add hugely complex rules and SCRUM documentation software then you take away productive time from developers and get little information as an output.

 SCRUM is about using time and resources in bitesize chunks in order to save the loss of time and resources in massive chunks.  The theory -as I understand it- is that a hundred ants working in unision can process a piece of bread much more efficiently and are much more adaptive to disaster during the work than 10 pigeons pecking at it.

As well as coding I also love extras, easter eggs and gimmicks.  Back when I could have been described as a hardcore gamer there was one such gimmick that came with the the Sensible Software series; the soundtracks.  These three (well, three that I know of: Sensible Soccer, Cannon Fodder and Sensible Golf) we’re amazing to me, speech in a computer game in the 90s was never this clear and was rarely this amusing.  Remember this was before MP3 had came along and made songs small enough to be stored on the 3.5” floppy that the game came on, back then an average song of this length would fill the 1.44MB that the floppy was capable of and some, so it was rarely seen.

It took me ages to find a copy of my favourite of the three but 1here it is…still just as amusing.

1'Sensible Golf Theme' [1994], Jon Hare

Comments: Not an efficient method of bug reporting!

Comments: Not an efficient method of bug reporting!