Tag Archives: development


My Understanding of Agile Development

Agile development seems to be the cool techy buzzword doing the rounds at the moment.  We’ve even started looking at the methodologies to put into practice at my workplace. I hadn’t really read much around it until the past week, but in doing so I’ve realised that my own software development process is pretty much Agile in nature already.  In this article I want to talk about Agile Development and my understanding of the general principles behind it.


So, what is Agile Development?

Basically, the purposes of Agile development are to make software development more, well, Agile..!  Agile means that software can be developed quickly, with plenty of interaction between customers and developers, meaning that new features can be rolled out regularly and based on equally regular contact between the stakeholders and those developing.  Rather than concentrating on the standard project-management, heavily documented development methodologies, Agile seemingly allows development to happen quickly and relatively effortlessly without beurocracy and forward planning hampering progress.

That’s my very basic take on it, anyway.

There are twelve guiding principles to Agile development, highlighted in the Agile Manifesto:-

  1. Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity-the art of maximizing the amount of work not done-is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As you can see, the guiding principles are really quite straightforward.  With regular and effective communication, early release cycles, a trusted team and high attention to detail (and what the customer wants), great quality software can be developed quickly and effectively.  In addition, the development team, whilst developing, need to keep up with current trends and keep their eye on the ball.  In terms of web development at this time, this is one of the more important traits any successful developer or team needs to have inbuilt.  With new technologies and developments (responsive design, HTML5, CSS3 to name a handful), it’s important to keep on top of the game to stay ahead of the competition and ensure that your customers get the very best at all times.

As I mentioned in the opening paragraphs of this article, in terms of how I’ve been working before learning about this, I’ve pretty much been agile in my processes already.  I meet at least weekly with my ‘customers’, make complete notes of changes and tweaks in the software I’m developing and then usually aim to make those changes and release in time for the next weekly meeting.  In the meantime how I develop solutions is left to me, and as long as the result on screen is what the ‘customer’ wants, we’re both happy.

This constant feedback-develop-release-feedback loop has resulted in some very successful projects in my time so far.  Bugs are quickly ironed out and I’m generally always very confident that my ‘clients’ have a piece of software that supports their work completely and effectively.  Any changes to the functionality of my work are usually quickly and easily implemented and again the feedback-develop-release cycle ensures those changes are successful.

So..there we have it in a nutshell.  There’s a hell of a lot more to agile development that I won’t cover in this brief article.  I rather just wanted to discuss the main points as I understand them in the hope that it might help those who have heard the buzz but aren’t sure what it means.

Any comments or critique are more than welcome.  Be gentle.

Access Work

What’s so wrong with Access??

Be prepared for a slightly ranty post, but with a twist (i.e this time not about infographics).

I’ve been developing applications using Microsoft Access for over ten years now, and I still find it an extremely easy to use, versatile and powerful application development platform.  I still regularly build systems with it today, although my time is now somewhat split between Access, Excel and ASP.

About a year ago I met with a colleague from another organisation to discuss a regular annual return we send to report on our organisations progress.  In these talks we discussed data quality and how we as an organisation store and analyse our data for export.  The bulk of the data I access for reporting either comes from information stored in an old and somewhat clunky Access DB, and the rest from a number of linked SQL server views containing information from our primary MIS.  It works well, and the queries/forms I’ve created provide all the information and reporting that we need.

This ‘data expert’ spent a great deal of time explaining how we shouldn’t use Access for systems development as it is ‘clunky’, ‘unsecure’ and ‘unreliable’ as a platform.  At the time this bugged me somewhat but I let it go.

Earlier this week at a conference in London I bumped into the expert again, and the first thing she asked was whether we were still using Access to develop some of our business tools.  I confirmed and I got a ‘look’.  The ‘look’ said ‘you need to move with the times, mate’.  We went our own separate ways and I started thinking about things..

Over the past couple of days I’ve come to the conclusion that she is wrong, and has probably only ever seen the ‘bad’ side of Access usage (and believe me, I’ve seen some really bad Access databases in my time).

I do agree that, at enterprise-level it’s certainly not the best platform as a standalone DBMS – you’d be much better served to have your data stored in one of the enterprise-level DBMS systems, such as SQL server.  That’s pretty much a given, especially from a multi-user perspective.

Where I disagree with her most is in terms of using Access to develop a reasonably sophisticated front-end, with data stored in a separate and scalable database – in fact this in particular is one of the areas in which I think Access still holds its own.  With the use of careful planning, a decent, reliable, secure and versatile application can easily be put together, but I think only as long as the application is developed properly and sensibly.

What do I mean by properly?  Here’s a brief list:-

  • Controls and forms should be unbound.  Creating, deleting and updating records should be carried out using VBA to ensure reliability and properly defined control.  Access wizards and bound controls don’t provide enough data validation or error-checking.  Any decisions on how to deal with data shouldn’t be left entirely to the user, and the system should have adequate business logic inbuilt to make those decisions and act accordingly.  With a decent grasp of VBA it’s actually very easy to implement such logic seamlessly and transparently to your application.
  • Data shouldn’t be stored locally in an MDB file if possible – any data used by the application should be stored in separate tables, linked for example using ODBC and whatever necessary authentication.
  • Access applications should be locally installed for each user, and not stored on shared network areas, where files are at risk of corruption or accidental deletion.
  • Security needs to be implemented properly.

I’m sure there are more examples of ‘proper’ development I could highlight, but I’m tired, and my main point is that I don’t feel that there’s anything wrong with using Access as long as the application is developed properly, securely and using VBA and robust programing practices rather than macros, bound controls or wizards.

Before anybody feels the need to respond negatively to my comments, I want to clarify that I’m aware that there are many better systems to develop in than Access.  I merely find it irritating when people dismiss it out of hand, especially if they aren’t aware of what the tool is capable of if used sensibly.

Another similar view on this can be found here (I even felt the need to use the same post image!)

Any thoughts or comments?  Keep them constructive, please.