Hard to believe that my 4 years of student life at the University of Dundee are coming to an end today. In some respects this has been an uphill struggle, in others it has been a wonderful, enjoyable and rewarding experience. I have made mistakes a long the way, I have learned important lessons and I have worked hard to better myself not only as a software engineer, but as a person throughout this experience.

I was planning on collating a number of resources and tit-bits of information and then posting them to the internal mailing list at university, however I changed my mind and decided to write this post making what I have to say open to all. I hope it is of use to someone as the advice I provide here comes from real, solid, “Been there, done that, got the t-shirt” experience.

Not all of it may be relevant to you but it has helped me. Use the links below to view each page (I apologise as it is rather long).

 

University of Dundee

Hard to believe that this is now week 9 of my penultimate semester/term at Dundee University, time has just flown in. While this is normally a good thing I am left realising that the available time to work on my honours project is deminishing rapidly. 

 

My honours project is focused around the management of software projects and teams across more than one methodology or management style. In-keeping with the theme of the project, I am working under an agile approach and will be utilising a number of aspects of Scrum (user stories, sprints, user-centred development, etc.) and because of this I am keen to enlist the support of the development community.

I am looking for open-minded people who will have a little bit of time going spare from January to April to play the part of the “customer” or “customers” in my project. My supervisors are keen to bring real people into the development and felt it would be a good to get some input from people involved in the software development process.

I am still in the planning stages of user involvement but I am aware of the need to start finding people willing to help out.

Ideally I am looking for managers a developers and designers in order to get a good spread of expertise and requirements although I am not expecting to get exactly what I am looking for.

More details of the project can be found on my Honours Project page.

During work on a security module I have run into the question of whether or not I should use a CAPTCHA technique on user registration or if an alternative should be employed.

CAPTCHA’s in my mind are quite frankly annoying, like many other web users I have run into my fair share of those that either just don’t work or are very hard to read/interpret. Because of this I felt that some research into how good they actually are at preventing or reducing spam and automated bots from registering was needed.

A quick google for “CAPTCHA disability” returns an interesting article on the W3C [http://www.w3.org/TR/turingtest/]. I draw your attention to the final two paragraphs of the conclusion:

The widespread use of CAPTCHA in low-volume, low-resource sites, on the other hand, is unnecessarily damaging to the experience of users with disabilities. An explicitly inaccessible access control mechanism should not be promoted as a solution, especially when other systems exist that are not only more accessible, but may be more effective, as well. It is strongly recommended that smaller sites adopt spam filtering and/or heuristic checks in place of CAPTCHA.

Lastly, new approaches focusing on using exclusively visual or auditory means for access control, such as the “PIN Guard” mentioned above, should be scrapped until a reliable method exists for users who cannot access them to authenticate themselves. A short-term security benefit is not worth threatening a person’s autonomy by denying them access to such important data as their finances.

OK, So given that what I am working on is supposed to emulate a small e-commerce website, I can take that on board and I agree. So the question becomes do you abandon this kind of check and “sort it out later”? Or are there other things you can do?

I found a a blog post by Slobodan Kovacevic in which two non-discriminatory approaches are explained, they are not a 100% guarantee against spammers but they can help reduce the impact.

The first one generates a unique hash string in the page session where the form to be protected is located when the GET request for the page is received. When the form is submitted the hash is validated and if they do not match the request is denied as it means that a direct POST request was sent. The idea is that anyone who wants to send the form data has to visit the page with the form first, it prevents automated form submissions over POST. As Kovacevic points out this does not prevent someone paying a human to process form submissions by hand but it does add an unobtrusive extra measure with a very small overhead.

The second idea is to use CSS (and maybe some JS as well) to place “bogus” form fields on the form using names that bots will commonly fill out. If any of these fields contain data when the form is submitted the request will be denied. Downsides to this approach are two fold; First if the user disables CSS or JavaScript (or is using technology which does not use either) the fields will be visible and can potentially cause confusion, two name fields for example. Secondly it feels a little, well “clunky” to me, generating extra HTML just to catch out spam bots? I could be wrong but I can’t help but wonder if that violates one of the unwritten laws of web design.

This is not a huge considderation in the grand scheme of things, but it does pose some interesting questions. If anyone has any ideas or comments on this, please let me know.

Today saw the end of one of the largest pieces of on-going coursework we have done at university thus far. 6 people working together in a group for 6 weeks using a methodology that only 1 of them had any solid knowledge of at the beginning.  So, how did it go?

Putting aside the differences in experience and ability, pretty well. I find it hard at times to accept that I have an advantage over many of my peers in that I have more experience in development and methodologies. I read the articles and the books, I play with the tools and I learn very quickly.

It took time but the group really began to work closely together and especially in the 2nd sprint were able to work around tasks and keep things moving along. Communication became more free flowing and a bond formed that made working together much easier.

I think everyone has benefited from this project and has taken away something valuable from it. To get hands-on experience of both Agile and Waterfall approaches to software development before entering the industry is not something I would say is common and I think it has been a great opportunity for everyone.

I am not a fan of rigid designs and reports, they have their place but often they stifle productivity and creativity. Agile is growing and I am quite sure that at least once in their professional careers the other students will work in a team that uses an agile approach. By having this experience they will be more prepared for it.

I want to say well done to the team for this amazing effort, you all did well and hopefully you enjoyed it as much as I have.

I would like to say thank you to our Customer (although I doubt he will ever read this, doesn’t hurt to be courteous), Colin from Live and Lets Dive for presenting us with this challenge and for supporting the students.

And finally I would like to thank Janet for the hard work and effort she has put into this module in order to make this as enjoyable and as entertaining as it has been. Thanks Janet.

And so the end, well only of this project. The blog continues, university continues and my never diminishing quest for knowledge continues. If anyone outside of Dundee University has been reading this, I do hope it hasn’t bored you senseless or left you wondering “what on Earth?”.

Oh, and can I haz ur blocks?

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!

Technically an off day for the agile project however Paul and Martyn researched the residual nitrogen calculations and came to a rather disturbing truth that all of the data from the PADI tables is going to have to be computerised.

While the research was going on there were some more problems with the source control however most of it is due to the team having to pick up an entirely new concept, let alone a new system. All seems to have smoothed out however, just got to keep reminding people of the steps the need to take in order to check files in and out.

Scrum master for the week is Stacey.