A lot of the time when we’re developing applications they’re likely to be based around customizing or extending an existing application, such as WordPress, Joomla, Oxid eSales et al. In these cases, there’s a clear set of rules and guidelines to work with.
But what about when we’re building our own applications, bespoke ones, from scratch. What about when we’re using a framework, such as Zend Framework or Kohana and the path is less clear? (which isn’t to say it’s unclear)
What do we do then? How do we set up a great software development methodology or set of processes to ensure that we develop cleanly, clearly and efficiently? In today’s post, I’m going to go through 4 areas which can serve as a solid and reliable basis for us to do just this.
Arguably the key aspect of developing great applications, besides a clear aim in mind, is the organized development environment or toolchain. If you’re not familiar with the term, toolchain is defined as:
In software, a toolchain is the set of programming tools that are used to create a product (typically another computer program or system of programs).
With a professional toolchain, you have a solid, tested and reliable set of environment with which to design, develop, test and deploy. One of the key issues that this relieves, when developing, is the amount of time taken to actually do the development work.
What we do when developing is develop. What we shouldn’t be doing is to think about:
All of these things need to be in place so we can just grab them and go.
OK, if a client’s requesting to us a different database or a new PHP module that we’ve not used before, then we need to spend time to integrate it into our development environment.
But with a solid development environment, we shouldn’t need to spend much time to make these adjustments and in the process make our toolchains even more robust and reliable.
So make sure that you have a well thought out and proven toolchain when you’re developing; a toolchain that contains the following (or equivalents):
Arguably equally as important as developing is deploying. If you regularly install desktop software and you’re a Mac user, then you’ll know just how slick Apple’s is with the .dmg files.
There’s no next, next, next, install like on Windows. It’s just double-click and OK, usually. Well, it should be pretty much the same for deploying your applications. Whether you use Phing, Webistrano, Hudson or a variety of other tools, other than changing your configuration to meet the needs of your new client, you should not have focus on this aspect of your development. But even this should be done with tools like Puppet.
It should be:
It should make sure that the code that you have locally is in one click deployed to your testing/staging environments and allow for a second click to take it from these environments to production.
Now ok, there’s no one size fits all here and different situations call for different measures. But I’d say it’s fair to say that you should never be running through a series of shell scripts, manually, to deploy a release.
Handling deployments in this manner is far too error prone, especially on a Friday afternoon, late, when the pointy-eared boss is glaring at you wondering why it’s not done, yesterday.
Far too often, despite best intentions and efforts, testing seems to get left to the last minute or just not done at all. There are a myriad of excuses that purport to be valid reasons. Anything from:
But how many times have we written code that we’ve come back to 6 months later, only to find scant, if any, documentation, and we’re scratching our heads wondering:
I had this situation recently and it’s partly why I’m banging on about it. After years in software development, I should have known better. It took some time to put all the pieces back together after searching and grepping through the code.
Gladly, now there’s much more documentation in place that, all being well, will be kept up to date as more information comes to hand. Don’t blow out your maintenance time and budget finding, repeatedly, what should have been written down in the first place.
Like most living things, software changes over the course of it’s life. What started out as a pretty simple and rudimentary application becomes a monolithic behemoth 5 years later. What leads to or compiles this issue are the changes in the other living thing linked to software – the organization that asks for it.
The original stakeholders go and new ones come in to take their place. Different levels of interest, understanding and priority of the application ensue. New requests come, bugs arise and are fixed, staff at the organization developing the application come and go.
If you’ve been working in software for more than a few years, you’ve experienced code that’s had a variety of developers on it who have exerted a variety of different styles. In short, without careful care and attention, the code’s become a mess a lot like spaghetti bolognese.
There’s code there that no one’s sure why it was put there, who it was put there by (unless you’re using version control) or when. That’s why a bug or issues database is a must – and using it diligently is too.
This way we can keep an accurate historical record of:
As new developers come in, this forms part of their initiation on to the application. After they’ve become familiarized with it, they will then have just about everything that they need at hand to work with the code quickly and efficiently. With such a plethora of such tools available, it’s mad not to use them. Not sure which ones to try? Here’s a selection:
So in this post, we’ve looked at 4 key areas of managing the development of custom applications by having a great software development methodology. These are:
How much have you taken these areas in to consideration when you’re developing bespoke applications? Do you see the benefits in using them in your organization?