Software Best Practices

So, hopefully this post is on-target with the goals of the Construx site, and I encourage others to make suggestions on the topic of single developers or those who manage themselves in a broad scope.

Hi Brian, Welcome to the Conversation!

I personally have done a little bit of solo development. Doesn't sound like pair programming is going to work well :-). Have you tried the Personal Software Process (PSP) by Watts Humphrey? How about short iterations with lots of demos to the client?

Hello Earl, when I read Brian's question I also thought immediately about the PSP. I have worked quite a bit with it and although it is the most complete process for individual software practitioners I would like to caution Brian that PSP is very involved and in my opinion overkill in its full version as proposed by Watts Humphrey. I normally suggest to study the whole process and then pick and chose those practices that make sense in the context of your individual needs.

Wolfgang

I have experienced the "one person does it all" problem myself. I work with a group of coworkers at a large company but the organizational structure is very vertical. Each person is in charge of his own project with very little overlap. We are slowly trying to change the culture to get more common code between the various projects. There is ample opportunity but some resistance.

 As a result I find myself doing things my way. I figure if I can't get any help I may as well do what I think is best regarding software design, construction, etc. This has led to schedule delays and no small ammount of pressure but in the end I think it was worth it.

 I agree with Wolfgang about the PSP. I downloaded the package of stuff and was immediately overwhelmed. As a single manager/developer/everything else you have to spend time on each role. One thing I've learned is that you must adjust your expectations regarding the ammount of work you can do and how long it will take. Tracking how much you can actually do in a week/month is probably the number one thing that will give you peace of mind and ability to plan. It will help you set realistic goals for yourself and use in your discussions with management.

Regards, Itrel

In my 25 years as a developer/manager I have worked as an "Army of One" or with a small group of professionals.  Wearing the hat of both developer and PM/Architect and even tester is a daunting and lonely task for certain.  When you have, essentiallly, all of the work to do, using processes and tools adds to the overhead. You want to be sure that the process and tools add value while being minimally invasive on your time.  We all understand the importance of process and tools so recognizing their value is not at issue but choosing the right process and tool is paramount.

My rule is I look for tools that impose a process I like, therefore, I get two for the price of one (in terms of effort).  I iwll make an example of a tool called KnowledgePlan which is an estimating tool.  It imposes a methodology that helps me build a WBS, forces a waterfall process (yes I know, it's antiquated, but I like it).  I can use the results not only for planning my development project but also for managing and scoping the tests.

Other than that I have created some of my own spreadsheets and Access databases to help with projects.  I find most tools to be high maintenance and high cost and I typically do not have the budget for either.  As for the PSP, my opinion is, it's great in theory, but not practical, at least for me.  Outlook task and calendar wirk great for scheduling, excel is outstanding for tracking WBS items and Word templates are sufficient for handling the paperwork.

I assume no on ehas developed tools for the little guy because there's just not enough potential profit in it.  So, in the mean time, as a lone wolf you are forced to forage on your own and improvise as you go along.

Brian,

I worked on 50+ projects from 1983 to 2002 for a major transportation company.  Most of the time I was the project manager, technical lead, data architect, systems analyst, and did most of the programming.  I always felt I my efficiency was lower than it should be and was always bothered by how informally I tended to manage projects.

What I have discovered recently by talking to the people I use to work with is that I was one of the most productive people in the department.  I also realize now that every project I managed finished successfully which means the level of formality was correct for the types of projects I managed.

I may be wrong but my assumption is that your projects are probably in the 500 to 1000 man-hour range and take 3 to 6 months to complete.  My suggestion is for you is to focus on rapid development techniques to increase development speed and time management to improve planning and control of the project.  You should buy a copy of Steven McConnell's Rapid Development, Ken Schwaber's Agile Project management With Scrum, and a good book on time management.      

@Earl:  I haven't heard of the Personal Software Process before, so I think I will check it out.  I read a summary of it, and anything that will help to get good project estimates is something worth looking at.

I am trying to have regular progress meetings with a demo of the work so far with the project team to get immediate feedback.  I think that is helpful for them and for me.  In my future projects, I will look to see how I can work them into the plan at good points in the project.

@Wolfgang:  You're right, the summary did give the impression that PSP is "involved."  I will try to get a good overview of the process and then dive into some specifics.  In my current project, I think the biggest shortfall is that the time estimates were way too low and the requirements were not defined clearly.  Those two factors pretty much force a rushed project with some perceived incompletness.

@Itrel:  That's pretty much my department.  There are a dozen of us, but we each have our own systems and applications to develop and maintain that there is hardly any overlap.  I don't see that changing.  We have the added bonus that documentation is low on the priority list.

@wtgr1:  You're right, its lonely.  And agreed, you need to be sure that the process and tools are worthwhile or else its a big impact to your project.  I have looked for tools that work in conjunction with how I want to do my day-to-day.  So far, the best I have found is called "Trac".  It integrates a wiki, SVN and bug tracking in one system.

@Scott:  Yup, I think you've described my situation pretty well.  In my previous job, I was considered very efficent.  I suppose my current job would say the same thing.  But personally, I know I could be better.  So, I want to strive for that.

My projects are on the smaller end of the scale, say around 1500 man-hours.  The dark side is that I have several systems I have to maintain, so my development projects have to fight with "production issues" for my attention.

I like the idea of rapid development.  I will look at the books you mention.  Thanks!

 @ALL:  Great ideas.  Big thanks to everyone.

My two cents:  Lately I've decided that Fridays are going to be my clean-up day.  This is a pretty low-level suggestion as far as "project management" goes, but for a single developer, that line is blury.  Anyways, I plan out Monday thru Thrusday based on where I'm at with my project and the next milestone, and then Friday is my cleanup day to make sure I've done the "paperwork".  It has been helpful.  I think if I can focus on just one week at a time, I don't get overwhelmed by the entire project.  Part of my missed effecienty is try to work on too many things at once.

--Brian

Brian,

I wanted to give a little perspective on what rapid development accomplished at the last company I worked for.

 Using rapid development methodologies (mainly proto-typing) we were able to cut development time by 50%r, development cost by 75%, and actually improved customer satisfaction.  These numbers are based on recent discussions with a number of managers and development people that I use to work with.

Steve McConnell's Rapid Development book is one of the most useful books I've seen on this subject.  I purchased and passed out 20 copies of the book 6 years ago and many of the people that received a copy still use it today.  

I was talking to an instructor in a project management class recently and mentioned this book.  This man has been a project management consultant for 25 years and currently helps major corporations fix their project management processes.  He indicated to me that at one point he purchased 35 copies of the book and continues to use the copy in his library as a reference.