I am the sole application developer in a company full of building developers, and such hands-oney people, it's my job to fulfil all the rolls that are required in the software lifecycle. As the company is getting more confident of my ability to meet their specific needs, they are taking on more adventurous projects. These projects are becoming more than just the regular old "I need a calculator to do this", or "We want you to make this program web based" kind of thing, to applications that require more forethought and planning.

I would say that one of my main weaknesses in the whole application development thing is my lack of experience in the design stages of a project. This is mainly due to the fact that I've been working in small companies since I left uni, and while I've learned the design skills, I've never really had an opportunity to use them or to fully understand the concepts involved.

In an attempt to keep up to date with the design requirements involves, I've been reading books, internet articles, and blogs to try and put togeather a process that fits my current position as "the one". Almost all of these sources assume that there are multiple people involved in the process (rigthly so), however, few really address the situation where your architect is your designer, is your programmer, is your tester, is your support rep, is your dogsbody.

I would imagine that this would be a fairly common circumstance, where there are relatively few people involved in the process of creating an application.

The current book that I am reading "Use Cases - Requirements in Context" (Kulak & Guiney), seems to be providing the most adaptable process yet for my own affliction. The book focusses on requirements gathering, providing a detailed process for the exercise.

In the smaller projects that I've worked on, I've found that the process of figuring out exactly what the application needs to do is one of the slowest most drawn out parts of the whole project. The main problem with it is that everyone has a different idear of what they want, and in some cases that I am just one person. The process described in this book gives pointers on what to watch out for, samples for documentation with complete walkthroughs on how to fill them out, and can be used in the single developer case just as easily it can in the development team case.

Reading the book kind of gets me itching to start the next project, just to try out some of the methods and see them in action. I wouldn't expect them to work for me strait off the bat tho, I'm a bit on the unenthused side when it comes to documentation and the like.. and this process will give you plenty. I guess, in the end, this is a good thing.