Tag: Development

Categories
Architecture and Strategy Technology Web Development

Thoughts on and benefits of task trackers and seperating support from development

Continuing in my series on professional development – see the previous article on documentation here (ok so there has been a bit of a pause and I am stretching things to call this a series – I had intended to post this some time ago!). This post concentrates on the benefits of using an Issue / Task / Bug Tracking Tool…

Keeping track of development tasks and issues in a centralised system helps enormously. Living without task tracking for your issues is a lot like not having having source control for your code. A good task tracking system – such as Fogbugz or Countersoft Gemini helps keep track of what the team needs to do, allows issues to be delegated / reallocated to more appropriate team members and enables multiple lines of support (eg 1st line, 2nd line etc). It also allows transparency on tasks (allowing Jane who requested a new developer to check the issue tracker for progress rather than interupting the technical team) and (particularly for those of us that need to follow ISO9001 type standards) provides an Audit trail if used properly.

Of course its not just about standing up an issue tracking tool – you need to agree on things like

– what defines an High Severity issue over a medium severity one? What Service Level agreements do we have and how does the issue track tie to those (eg does selecting medium mean response within a day as opposed to high which requires a response within 1 hour for arguments sake).

– What is the process from issue inception through to resolution (does a new change request issue go to Bob -or better Bob’s role “Change Manager” – who allocates it to someone to estimate and changes the status to pending estimation).

– What level of documentation are you looking for in the comments associated with a case – is just referencing a source control commit enough (which is ok if your source control commits are verbose) or do you want a short explaination of what was done?

Clearly if done right this can allow your team to scale and stop your developers getting bogged down with admin (make sure there is someone overseeing the issue tracker). It can also make it easier to seperate support work from new big development work (the former you can give to junior colleagues to help them get up to speed with support from more senior ones – preventing senior guys/girls from getting bored with smaller stuff).

One other observation on this is that whilst you do need to be strict in order to implement these tools (eg ensuring that folks always use the tracker rather than continuing to email you all the time) you need to make sure they don’t become a barrier to communication between the technical team and its customers. One thing I like to do when involved in an operational issue is to cc the issue tracker in on an more detailed email explaining an issue – the customer gets a personalised response and the issue tracker captures the commentary (preventing time wasted by copying and pasting).

Would love to hear others thoughts on their use of issue tracking systems and the pros / cons.

Categories
Open Source Technology Web Development

Wowed by upgrade to WordPress 2.7…

Have just upgraded to the latest and greatest WordPress and was shocked as it has wowed me again in terms of user interface. The pace of improvement of this Open Source product is incredible. Just as I think wouldn’t it be good if… they’ve done it in the next release (and improved stability / fixed bugs).

They’ve introduced a turbo button which makes use of Google Gears (the offline/browser enchancement) and added more time saving shortcuts and a better post writing interface (particularly for re-using existing tags on new posts – this UI for tagging taxonomy might have to be borrowed on some of my projects…) Read their blog post here for more info on features (includes a video).

Below is the new dashboard – compare the below to WordPress 2.5 that I upgraded to back in May 08

fireshot-capture-5-olivere28099s-yard-ollie-cronke28099s-blog-e280ba-add-new-post-e28094-wordpress-blog_cronky_net_wordpress_wp-admin_post-new_php

The new dashboard is below – it now has dragable “modules”

wordpress_wp-admin

Trouble is it now makes me want to upgrade the design of my blog – but I know I have way more important things to do with my time before I faff with that again!

Categories
Open Source PHP Technology Web Development

Professional Development – Part 1 – Using a Wiki for Documentation

This will be the first in a series* of articles on web applications development – not the specifics about programming, but more tips on the infrastructure and processes that can make life easier, more productive, successful and better aligned with best practises. Its based on my experiences of being in development teams and leading development teams.

I see these articles as being useful to a development team thats growing from a 1 or 2 man operation to a larger team and is perhaps using Open Source development tools such as PHP/PERL/Python and perhaps aren’t in a very processes driven environment…

Documentation

Most developers won’t generally document their work as a matter of course – either they simply forget, overlook it or its just not that exciting for them. So 3 things:

  • Illustrate the value of documentation
  • Build it into the development process
  • Make it exciting (oh okay you can never make documentation that exciting – so lets settle for a bit more interesting!)

Illustrating the value – most developers are already sold on documentation being a generally good idea but others aren’t. Some fear that by documenting they loose control over the project or the work that they primarily work on (in fact the reality is that is the opposite…) or they just really don’t see the point. Highlight the facts that it enables team work, improves quality, makes support and changes easier etc. Also that holding all the knowledge up in your head means that you are stuck in your current role as its not easy to bring others in to do what you do so you can be promoted.

Another great benefit is inducting new team members – it allows you to point new team members at the wiki site to help them get up to speed quickly – and you can also use that process to fill in any gaps in the documentation (and get the new start to include their tips and findings as they learn the ropes…

Build it into the development process – obviously you need to have a development process if you haven’t got one but once you have it just becomes part of the steps:

  • Requirements Gathering – document
  • Spec/design – document
  • Build/development – document

So ensure that documents are required for each step in the process – and make time for that documention. The nice thing is that documentation is a lot easier if done throughout the project life cycle rather than all at the end (then it is just really daunting) – as generally what you plan to do is what gets delivered (and if things deviate from the spec during development you can just adjust it)…

Make it more interesting – its more that just that in reality as its picking a documentation tool that supports the above points and works for the team. For me development documentation seems to works well with an internal/Intranet Wiki (something like MediaWiki for example). The main benefits (over office docs for example) it allows easy collaboration, allows for a geographically disbursed team and is generally nicer than using word processing software. It’s made more interesting by feeling very “Web 2.0” (as much as I hate the phrase!) and has some great tracking features – like the recently edited articles page. Once the team have seen the advantages and you bore you colleagues to death with “the W word” then you’ll find that you have a healthy wiki site and documentation, documentation, documentation (with any luck with minimal pain!)

Categorising the Wiki – here are some ideas on some categories that work:

  • Projects – Pages under here relate to discrete projects the team is working on
  • Infrastructure – documentation on the dev, staging and production server environments (eg Server configs, IP addresses, SLA details)
  • Process – Reference guide to the development and other IT processes so the team can refer to them and also make contributions and feedback on what is working.
  • Meeting Notes – Agendas and minutes for meetings – if you get this right then these allow for team communications when needed (rather than at forced meeting dates) and are links to other pages on the Wiki where the full details of a proposal or a project is available.

Blogging

Another option (which has some other positive side effects including marketing) is blogging about development projects – and this is something I am considering for my current team. The Wiki will be for the more technical and internal documentation aspects and the blog for what the project actually does. The added benefit of the blog is that it can do some link / SEO stuff for your projects and raise the profile of the development work that your team is doing to a wider audience. This is particularly useful if you develop an Intranet system for your company – where you are adding new features or enhancements over time.

To make MediaWiki easier to use (for those who aren’t familar with the syntax used on Wikipedia) we enabled a WYSIWYG editor – FCKEditor. There is a whole range of great Wiki software out there if you don’t like the look of MediaWiki – just do a Google or have a look at wikimatrix.

The next articles will more than likely be about:

  • Project Management tools (eg FogBugz) –
  • Development Meetings and Communication
  • Using a Framework (eg Zend Framework)

… watch this space!

*I don’t know how many there will be yet but if they are received well then heck there might be as many as 3 or 4!