Ahh, vast improvement on last sprint!

We met Janet (the Customer) and not only did we impress by asking if she would like coffee, we had refined our approach, presented what we had done and explained it clearly. Despite not having that much completed it actually look far more impressive than I thought it would.

As a team a lot of hours and work went into this second sprint and it was great to see that it had paid off and that most of the points that hurt us last time round had been resolved. We could have been more organised on what would be done in the theoretical third sprint but that really slipped our minds.

I am glad I threw in the little launcher application at the last possible minute, otherwise we would have needed a recompile mid demonstration, that would have been about as bad as showing raw XML or opening the sprint backlog spreadsheet (despite the fact I am quite proud of how I got that looking in the end, and thanks to Alan I learnt how you can restrict the values of a cell).

We did need to go back after the review and just tidy up a few loose ends for our coursework. Rory and Stacey made a really cool white box testing diagram, Alan and Paul finished up the black box testing and I sat and frantically collated all of our code, tests, backlog, etc.

I really enjoy the feeling of a team working together like that, even better against a deadline as it makes me work that bit harder.

So, as far as the review goes, amazing improvement and I really do hope everyone else feels the same.

Note to Janet:

This post and the one after it were written on Friday however I could not post them till Sunday evening.

 

Ok, that is a very direct, generalised and harsh statement but if you are reading this, then it got your attention. So let me explain why I would write such a thing

During my weekly activities with the group this week (see AC32002 for details) a number of realisations and observations came to my attention and were then backed up by recent articles in the media regarding the IT skills shortage. I started thinking about this in relation to the people who are supposed to be filling those gaps in a couple of years, my fellow students. At this point in time I am in my third year of Applied Computing at Dundee University in Scotland. Students who started in first year have been taught the following:

  • Java
  • Data Structures (Stacks, Queues, etc.)
  • Web Authoring
  • HCI (at varying levels)
  • .NET (VB and C# 2.0)
  • ASP.NET (in VB)
  • JSP
  • C++
  • Design Patterns
  • Waterfall and Agile methodologies (working on Agile at the moment)
  • Databases (mostly relational but also covering the theory, use and design)

So, really a very solid covering of things for 3 years of work and bar some minor organisational issues has been very well taught and structured. The majority of the material is relevant, the lecturers and staff know their subject areas and teach them well. We have outstanding facilities, the Queen Mother Building was opened three years ago and is a magnificent work of both architectural ingenuity practical design. Inside we have (usually) enough mid-level machines to meet the needs of the first three years that use them, dedicated hardware, software and research labs for areas of study, the list goes on.

Where am I going with this? Dundee University, like a number of institutions in the United Kingdom put a lot of money into their IT-based subjects since that is a huge growing market that needs people to fill the jobs. What I realised this week after discussions with my peers was that a in theory a good, employable student needs two things: The tools and the willingness to learn and better themselves. In essence a “good” (I am sure there is a better word to use here, I am just missing it) student has a passion for the subject they are studying.

So what has that got to do with anything? Students aren’t known for being “perfect”, in fact that is part of the idea of a student. You go to university to learn, to be taught more advanced and in-depth concepts from those at school or college with the goal of finding a job that requires the skills you have studied. What I have started to notice, and it is not limited to Dundee is that there are quite a number of students that at this point don’t go that little bit beyond getting the grade they need, they don’t look deeper into a subject to find out the “how” and the “why”. As it was pointed out to me this week there are still students in my year that don’t even pick up their assessment feedback, they look at the grade and either go “I will do better next time” or “oh, OK, I live with that”, not every student actually reads the feedback they have been given and go find out how they could improve on that in the future.

It does seem to be that getting the grade is of the highest importance and anything beyond that is a waste of time and effort. Part of working in software development is being able to see where you could improve your work in the future, always reassessing the technology and your development styles. There are situations where simply getting the code to work is not going to cut it with managers when a certain level of code is required or a certain methodology must be followed.

It is one thing for a student to achieve a given grade, it is something completely different for the same student to learn from it, to look at it and think “How could I improve on that?” and then actually apply it on their next assessment without even needing to be asked or told to do so.

Now University is a very intensive thing, we are currently swamped with work and it is hard, but to me, that is not an excuse to cut corners. And of course not all students do, that is not what I am saying here at all. There are many students who have begun to realise that they don’t only need the mark, they need an understanding of the work and as such there have been some really good projects and discussions to come out of it, what does concern me is the number that actually do this.

This is all conjecture and purely based on what I have been listening to, reading and seeing. Perhaps I am reading too far into this, perhaps I simply went into university with my expected standards set too high but then if I am in a job and I have to work with someone in a team, I would expect a certain level of knowledge and understanding if they have been hired to do the job.

Comments welcome.

 

I made a number of realisations today, let me list them:

  1. We really needed to sit down as a group and think long and hard about how those dive tables were going to be stored and also how we can access them with a computer.

    Why?: Everyone who has looked at those tables has a different picture in their head of how they are being computerised, we don’t seem to have a single solid idea of how this is going to work. For example the table columns that Stacey and Alan used are partially inappropriate for actually accessing the data using a computer. I actually wrote code today that looks up a column, goes down to find a cell with the required data in it and then comes back up again to reference another cell just to get the residual nitrogen. That is very bad design and the time it takes to process is actually noticeable!

  2. We underestimated the time that the computerisation of the tables would take.
  3. Complex tasks often require more complex approaches (or simple approaches that use what can be considdeed “complex” implementation from those who are unfamiliar with them).

    This is more a failing with me than anything else. Presenting the group with the knowledge on how they can access the dive tables and use that seemed simple to me, evidently this isn’t the case.

The entire team really had to pull together today in order to get this block cleared out, all of the pairs plugging away at tasks and programming to try and move forward. The end result was code that could look up the tables and it managed to perform one of the calculations however doing much more really required a re-design of the table structure and so we could not implement it in the time we had.

I do feel we have better prepared for tomorrow however, we know what we did wrong last time (and I sure wont be turning up late nor looking like I have been run over by a hummer a couple of times). In essence better but could still be improved further. But then that is part of what we do in life, continually try and improve ourselves.

 

I knew it was coming, and it happened today. I ended up driving the refactoring of the computerised dive tables, we needed to get things back on track and so Paul took the navigator seat and I hammered out the code. In actual fact what Stacey and Alan had created was on the right track but embedded all of the tables inside of a class which was going to get very messy indeed.

I shifted out the tables into a comma separated file and fixed the interface to access it, Paul was quite interested to learn some of the techniques I use although I did get the feeling I lost him in places. Under normal circumstances I would have navigated and let him drive, teaching him the parts he was unsure of but the rest of the user story was held up waiting for this as it is and so this is how we solved it.

There is still more to do but it should provide a base to continue on from.

We also had a meeting with Janet (the Product Owner) in order to resolve a couple of minor discrepancies on our acceptance tests. These were to do with values we had used previously being off slightly.

 

Ah, the one thing Agile and Scrum seek to avoid has struck once more!

Yet again we have a coding task blocking us from moving forward, we thought we had avoided this problem by better defining our tasks however it would appear not. We cannot write code for calculating the residual nitrogen until we have an idea of how the tables are going to be represented and store. Perhaps this should have been designed better but then we have different levels of skill and ability in the group so that is one of those “Oh, we should have thought of that” type problems.

Anyway, while Alan and Stacey were working away on that Rory and I moved on to the third user story and actually managed to take care of a number of the tasks (design and GUI implementation). Was quite nice to see the chart start to go downward on the next story, gave a nice feeling of concurrency (or perhaps that is just John Arnott’s Computer Architecture lectures going to my head!).

The pair programming seems to be going more smoothly this time around, all three teams working hard on their tasks, was a very nice atmosphere.

A couple of quotes from today that made us all smile (after seeing a comic strip about the upcoming Lego online game):

“Learn to build n00b”

“Can I haz ur bricks?”

The Refactor Tractor has been beaten….by Lego!

© 2011 Andy Gibson
Header image courtesy of Don Solo
Suffusion theme by Sayontan Sinha