Agile Development Reconsidered

The software department at work was gathered for a QA meeting the other day. I was quaking in my boots as to the box ticking possibilites that could lay ahead, however I could not have been more wrong! Phil (my boss) started the meeting by saying something along the lines of “from now on, unless a process helps us, or is legally required, we get rid of it”. I couldn’t agree more.

I’m increasingly thinking that “agile” is more a state of mind then a set of methods/procedures to be followed. You can code in an agile way, without following specifically agile methods.

Consider the following list:

  • Keep documentation to a minimum (and keep it D.R.Y);
  • Automate testing as much as possible (and keep the testing cycle running continuously);
  • Aim to write as little code as possible (less code, less bugs);
  • Nothing should ever be committed without being doxygenised (or similar);
  • Agree upon and maintain a [minimal] coding standard, adhere to it and enforce it;
  • Have a rough plan for the next couple of months, have a precise plan for the next couple of days.

These are not things that are specifically agile (or ground breaking), but are all things that a lot of companies don’t do.

What do you think?

7 thoughts on “Agile Development Reconsidered

  1. Document APIs, mostly by example.

    Automate all testing.

    Use a programming language that doesn’t require you to write any more code than necessary.

    Use a programming language that reads like english so doxygenisation is redundant.

    Use a programming language where the community enforces a common coding style so you don’t need your own standards.

    Planning is good.

    In essence, I suppose Agile Development is made possible by the right tools/languages, received design patterns, and the displacement of documentation/QA overhead by rigourous automated testing.

  2. I like doxygen, because it gives a way of understanding/learning about APIs and applications without having to read the code.

    I don’t think that it is possible to automate all testing. The project that I am working on at the moment requires a certain amount of objectivity, something that computers are not capable of.

    As far as the language is concerned, I know you think that RoR is the solution to all of mankind’s software woes, but I still think that languages like Java (and to a certain extent C++) have a part to play. Having said that, I am currently learning to use Mootools and plan on learning RoR afterwards.

    The point I was trying to make in this post, was that you don’t have to chuck all your working practices out of the window to become more agile. You just have to make the decision and go with it…no post it notes required!

  3. Can you give examples of tests you are performing that can’t be automated?

    I wouldn’t say that RoR is the only solution. Ruby would be too slow for some applications and Rails is only for web based stuff.

    However, I believe modern dynamic languages like Ruby make software easier and quicker to develop, albeit at the expense of runtime performance.

    From a programmer’s perspective, an ideal program would consist only of statements that directly contribute to the resolution of domain problems. Memory allocation/deallocation, strong typing, variable declarations, threading (mutexes, semaphores, etc), empty base class methods, templates/generics… are all examples of the extra code we shouldn’t have to write.

    Mootools doesn’t integrate so well with Rails as Script.aculo.us, because Rails has helpers for Prototype/script.aculo.us libraries built in. Having said that, I think there is a project underway to develop a Moo helper for Rails…

    With regards to working practices, I don’t think I ever had any, which may have been my downfall. I’m still wondering if the tendency towards formal process/QA/working practices/procedures is a solution to the wrong problem.

  4. I can only give vague examples I’m afraid. Think of things that for a given input, could have numerous outputs – some of which might not be wrong, but aren’t exactly right either. It’s really hard to explain without actual details!!!

    Don’t you think that a lot of the things that you would do away with are things that would not affect the end user (e.g empty base class methods), you are looking at things from a strongly developer aspect. The end user is always going to value execution speed over your happiness. I can see that some of the detritous could be handled by the compiler though. (Sorry, I just realized that you want to get rid of those too!)

    I already switched to script.ac.ulo.us, it looks slightly easier to pick up. I scoped out your cock and took it from there!

    Working practices are just there to make sure everybody does their job properly. Even if you were able to assemble a team of engineering saints, they would not be able to work without such procedures. To quote Monica: “rules help control the fun”!

  5. I’m not sure I accept you explanation of tests that can’t be automated. Tests still need to be repeatable, even if they are carried out manually.

    I would argue that helping the developer directly helps the end-user. If coding is easier, the end-user is more likely to get a system that works properly. If coding is quicker, there is more scope to be Agile and refine functionality to be closer to the end-user’s inevitable emergent requirements.

    I still searching for ideal ‘formalish’ working practices that make a positive difference without excessive overhead.

  6. Emergent requirements are the big thing that agile addresses, but I don’t think that it is impossible to manage such requirements without using Scrum or similar. An iterative approach will mean that lots of builds can be delivered to the customer and as long as feedback is gathered before beginning the next iteration (i.e. not endless overlapping cycles of builds, bugs and feedback) it should not be that troublesome to change the code. If it is, then I would suggest that it speaks more to the quality of the design, than of the language. I’m pretty sure I could write some horrible Ruby, given the chance.

    I take your point about speed of coding and think that Java/C++/modern OO languages could be improved, I just think that there is a halfway house between them and Ruby.

    I actually think we may end up seeing the advent of a W3C recognized language-type-thing. More and more applications can be run happily in browsers, and if you are standards compliant, you have cross platform compatibility for free (unless you use M$ Internet Exploder). You don’t need to be online to run a browser based app, but obviously it would make things easier. Plus, the subscription based model lends itself to this sort of setup and that also seems to be the way things are going.

  7. Yes, it is no harder to write horrible Ruby than any other language. In fact, it’s almost certainly easier!

    However, there are things you can do very elegantly in Ruby that can only be achieved in a horrible way in C++ (or Java). Everyone wants to have a more declarative programming style these days, but the C++ STL algorithm approach to this is so nasty, most people stick to good old fashioned ‘for’ loops, because they can’t get all the ‘mem_fun_ptr’s and ‘bind2nd’s to compile… And even if they get it to compile, the intent of the code is intractable.

    With regards to a ‘W3C recognized language-type-thing’, I think the next step is to allow a standard virtual machine (like the JVM) to interact with the DOM to the same extent that JavaScript can. Then, any language that can be compiled down to byte codes for the VM could be used client side and probably server side as well. That would tidy up web apps no end!

Leave a Reply

Your email address will not be published. Required fields are marked *