The year was 1993 and I did an honours year at Curtin University. I was awarded a Lower Second. It was late by a month and they said it was worth an Upper Second. FYI – To get First Class you need to doing an original piece of work. I was extending something already started.
Was that a valid reason to give a lower score. Others were late but apparently gave good excuses, like finishing a piano competency and some others I don’t recall but sounded equally invalid.
I decided not to contest. Dates are not a valid measure as such. It someone finds it valuable then this should not matter. That said managing WIP and slicing work would’ve helped. But despite this we still get it wrong and yet we place so much emphasis on deadlines and their cousin estimates.
I did something more valuable in retrospect. I was a student councillor and I created a magazine and got people collaborating. Getting a lower mark on a lone pursuit is a small price to pay then so be it. I get and still receive criticism for it. I think they are wrong.
Do something that aligns to your ‘Why‘ as Simon Sinek would say. Conformance leads to mediocrity I think.
For those interested the work of the thesis (1, 2) was on MIME – the start of multimedia in internet email. The stuff in the work is now so everyday it’s really dated. If I had known about Visual Basic I could have created a program in 20% of the time as compared to C and X-Windows. It could have been in earlier even. But I could not be seen to be using a simple language at a University. LOL.
It’s still worth an Upper Second for the time – if they said it was!
Mind maps from some sessions at Agile Adria 2015 held at Terme Tuhelj just outside of Zagreb in Croatia. They are rough but still good memory joggers. More may flow from these depending on time.
Joshua Arnold – Cost of Delay
Vasco Duarte – Product Owner Toolkit
Tom Gilb – Power to the Programmers
Miroslav Oračić – Restructuring at Hrvatska Pošta
Mary Poppendeick – The Scaling Dilemma Part 1
Mary Poppendeick – The Scaling Dilemma Part 2
Mary Poppendeick – The Scaling Dilemma Part 3
Mary Poppendeick – The Scaling Dilemma Part 4
Mary Poppendeick – The Scaling Dilemma Part 5
Stephen Parry – Closing Keynote: Staying on Purpose
A reminiscence. Remember the basic graphics and sound of those early games. Here’s a simple game called Gridder I cloned from a Commodore 64 game called Supergridder. It’s written in C. I was infatuated with this simple game of the C64 and thought it an interesting project to write my version of the game as a project.
Screen 2 of Gridder
To run it you will need a Dos emulator like DosBox. You will also need to slow the CPU speed down in the emulator. In dosbox you can use Ctrl-F11 to decrease the CPU speed. Use the mount command in the emulator to access the downloaded game on your local hard drive e.g. mount c c:\temp.
When the game was written it worked on much slower hardware. It’s quite hard to play when it’s too fast. If you have an ancient dos machine it will probably still run.
The idea of the game is to fill in the borders of the rectangles to cause a rectangle to be filled in. At the same time the player needs to stay out of sight of the two bugs. If you are caught you lose a life but you can put a temporary gap between you and the bug by pressing the F1 key. On completion of a screen you move onto another screen with a different layout. You score by filling in rectangles. Complete a screen fast and score a bonus with the time left on the countdown timer added to your score.
In computing’s earlier days some 25 to 40 years ago we had a big tussle on for software development methodologies. In 1993, I and another Honours Student wrote about some research we conducted to catalogue just some of them, and yes there were a lot, and we produced this paper in all its student glory (part 1 and part 2). I don’t have the electronic version anymore, rather the scanned copy which I somehow manged to divide into two sections during the scanning process i.e. paper jam.
We started with methodologies that were somewhat driven by the technology at the time. For example procedural based languages created a number of Structured System Analysis models like Edward Yourdon’s (Modern Structured Analysis) also covered by Meilor Page-Jones’s famous book Structured Systems Design. Information Engineering was somewhat data driven and made one of its originators a lot of money that he was able to live it up on a Carribean Island for the rest of his days. Some, fortuntately did emphasis the people side of things. The paper acknowledges this as generations of methods emerged.
This is where we have got to today. People still create software and usage of ‘guides’ like Scrum, Kanban and some hybrids specifying varying levels of details recognise this. Various prescriptions work in different contexts and our job as developers of solutions is to apply the right methods.
Furthermore the prescriptions I’ve seen attempted over the last 20 years have all been, to put it bluntly, been terrible. Rational Rose’s Object Oriented View of the World was an improvement but still smelt of documentation beauty rather than delivering real customer value. Consulting firms tried to market their methods and created massive tombs of unreadable text that no one bothered with anyway. I remember reading in 2003 DMR’s (now Fujitsu Consulting) massive metholodolgy – they must have been thinking that execution word for word would produce the system everyone wanted. It never happened quite the way the authors expected. Prince2 is a repackaged variant of documentation heavy methodology which seems to be implemented by automatons keen on producing wonderfully thick documents with idiosyncratic diagrams and prose of the authors own concoction and no one else’s that should be filed in fiction in the library. I’m not sure the claims that Prince2 can coexist in an Agile environment, the way I saw it implemented says no. It could’ve have been that they didn’t understand that cross functional teams, a backlog, a willingness to create working software early and regularly and to break dependencies is critical to it’s success (credit to Mike Cottemeyer to making this stark).
Agile is certainly an improvement, but as we learn more about human interactions we can expect more improvements in the coming years. As for a tussle, it’s still a tussle given the way I observe the interchanges amongst Scrum, Kanban and the various scaling approaches.