I was asked the question "What is your process when developing an app". I was not exactly prepared for an answer, much less one I could deliver as a short 30 second pitch for my skills as a developer.
But it got me thinking. I do have a process, even if I've never codified it. Part of this process involves my secret weapon (though not really secret).
Maybe I am just old. But I still enjoy paper, and really anything paper related. Even as a child, I always had a pad of graph paper for recording my ideas. But that's not my secret weapon.
The venerable pencil is my weapon of choice. The pencil is to me what a wand is to the magician. Its a tool to focus my "magic" and channel it where I want it to go (usually onto graph paper, but a nice Moleskine notebook is also good, as well as the proverbial napkin).
For me, holding a pencil in my hand allows me to think in a serious manner.
That is where my process begins. By putting ideas onto paper. This, for me, makes things real. The flurry of thoughts in my head coalesce into words and sketches and are recorded more less permanently. A pencil, as opposed to a pen, allows revisions and updates where needed.
First, a simple list or even tree of idea points, features, and even references to other related things. After that, some visual sketches. This in particular is where graph paper comes in handy. With all the technology, the styluses, the touch screens, still nothing beats a pencil and paper.
But we are still talking about application development here (actually this is my process for everything, from how to restore my kit car to developing a recipe), so eventually I will transfer those ideas to a "mind map", my favorite tool for this being Mindmeister. I like the simple, purpose built tools.
Now, I like agile as much as the next guy, but you are kidding yourself if you think you can bring any reasonably complex project to fruition without some kind of plan. This is why I like to create a functional specification document. Yeah, I know, this starts to sound like big corporate speak and more like waterfall style development. But honestly, if you can't describe your project in a few pages (or even one page to get the gist of it) you probably have a problem.
Think of your functional specification as a sort of pitch for your idea. It's as much for other people as it is for you to help you stay on target. Keep it to the minimal requirements too. Just what is needed to make the thing viable. It's like writing a short story, you only throw in what is absolutely needed.
Getting down to actual development, I might use a tool like Ionic Creator to rapidly develop a prototype to show other people. At this point I've probably also got a kanban board (Trello is a good simple tool for this) as well as bug/task tracking (I'm often forced to use Jira but I prefer simpler tools like Fogbugz). I cannot remember what I need to do without tracking it, so these tools are invaluable. I shouldn't have to say it, but use version control (Git). Use branching and tagging to track versions and releases and lines of development.
The rest is a series of iterations over adding features, testing, refining, testing and more testing. I cannot stress testing enough. Think about every edge case. Every "user story" (you should have some of those in your functional specification). Keep your iterations short, that's really the meat of agile. And if something doesn't work out, don't be afraid to back up (you are using version control right?) and try it a different way.
Oh, and listen. Listen to your client. Listen to other developers. It's easy to develop an ego and start thinking you know what's best. Most times you may be right, if you've been doing it long enough. But sometimes you will be wrong. Listen to what others have to say and be willing to accept the good ideas. Unless you are just building this for yourself, you need to understand not everybody thinks the way you do. Sometimes, a compromise must be made to adapt to what people want.
But it got me thinking. I do have a process, even if I've never codified it. Part of this process involves my secret weapon (though not really secret).
Maybe I am just old. But I still enjoy paper, and really anything paper related. Even as a child, I always had a pad of graph paper for recording my ideas. But that's not my secret weapon.
For me, holding a pencil in my hand allows me to think in a serious manner.
That is where my process begins. By putting ideas onto paper. This, for me, makes things real. The flurry of thoughts in my head coalesce into words and sketches and are recorded more less permanently. A pencil, as opposed to a pen, allows revisions and updates where needed.
But we are still talking about application development here (actually this is my process for everything, from how to restore my kit car to developing a recipe), so eventually I will transfer those ideas to a "mind map", my favorite tool for this being Mindmeister. I like the simple, purpose built tools.
Now, I like agile as much as the next guy, but you are kidding yourself if you think you can bring any reasonably complex project to fruition without some kind of plan. This is why I like to create a functional specification document. Yeah, I know, this starts to sound like big corporate speak and more like waterfall style development. But honestly, if you can't describe your project in a few pages (or even one page to get the gist of it) you probably have a problem.
Think of your functional specification as a sort of pitch for your idea. It's as much for other people as it is for you to help you stay on target. Keep it to the minimal requirements too. Just what is needed to make the thing viable. It's like writing a short story, you only throw in what is absolutely needed.
Getting down to actual development, I might use a tool like Ionic Creator to rapidly develop a prototype to show other people. At this point I've probably also got a kanban board (Trello is a good simple tool for this) as well as bug/task tracking (I'm often forced to use Jira but I prefer simpler tools like Fogbugz). I cannot remember what I need to do without tracking it, so these tools are invaluable. I shouldn't have to say it, but use version control (Git). Use branching and tagging to track versions and releases and lines of development.
The rest is a series of iterations over adding features, testing, refining, testing and more testing. I cannot stress testing enough. Think about every edge case. Every "user story" (you should have some of those in your functional specification). Keep your iterations short, that's really the meat of agile. And if something doesn't work out, don't be afraid to back up (you are using version control right?) and try it a different way.
Oh, and listen. Listen to your client. Listen to other developers. It's easy to develop an ego and start thinking you know what's best. Most times you may be right, if you've been doing it long enough. But sometimes you will be wrong. Listen to what others have to say and be willing to accept the good ideas. Unless you are just building this for yourself, you need to understand not everybody thinks the way you do. Sometimes, a compromise must be made to adapt to what people want.
