Month: November 2005

Development times can be long. You might have been developing a system for months, or a year, or many years.

Specifically, I was thinking about the initial stage of development, before a launch. After launch, well … it’s a long road, bugs, new functionality, user complaints … etc.

But for the Initial Stage you are alone pretty much, especially before any kind of alpha testing happens. It’s you (team/individual) and your code.

1. This is a good thing.You control the destiny of the project. You have the blueprint, the direction, no matter how developed that plan is. You can push further, put together systems, management tools, methods of practice.

   Breaking down the project is a must. To achieve smaller blocks of code/functionality/development will be far better than just approaching the whole entire blob and "just do it".

   So how do you break things down? From my experience, spending a little time with this is going to bring dividends almost instantly, and onwards. It’s possible to chop up a project into functionality breakpoints. This is probably the most likely way to go. In fact, it’s how my current project is done.

   However, I’m beginning to wonder if we shouldn’t approach things from a slightly different perspective. I haven’t got any concrete ideas here yet, just some possibilities. Anyway …

   How do you split up a project functionality wise? Mostly chronological. But then, if you’re developing from scratch, how do you plan for functionality that isn’t known yet, but will be discovered along the way? Problems that will arise by going down a certain database design track? Methods that will break other methods in the future?

   I haven’t been in the business long, but so far, I haven’t found a super answer. Just a little one. Make sure that things are done simply. If I can understand the project simply, then break down that into more little simple parts, then things move easier.

   That’s not to say problems won’t occur. They will. But so far, I’ve found that the harder you work at making code/structures/development simple, the better equipped you are to deal with any issues along the way.

2. This is a bad thingEspecially for a project that takes more than six months (and you are a small team, or individual), how do you maintain enthusiasm through this time? After a while, even the small breakpoints can lose their lustre. Weekly meetings can be bluffed, although I’m not sure about daily meetings. That would probably help. The Scrummaging methodology comes to mind here.

   But then, that wouldn’t be enough. If you don’t have motivation, then productivity will fall.

   The first Motivation (big ‘M’) that comes to mind is that of job security. It’s the big one I guess, for most people. [ Marge: The plant called and said if you don’t come in tomorrow, don’t bother coming in Monday. ] Homer: "WOOHOO! 4 day weekend!". Well, that’s a Simpsons quote, but you get the point.

   However, I don’t think that it should be very important. It can be a motivation, but it’s not going to solve the heart of the problem.

   The "heart" of the problem? It’s a few things. Job satisfaction. The ability to develop relationships. Physical health. The ability to grow relationships. Mental health. The ability to foster relationships.

   Hmmm.

   Now, I know that this might be a problem for people. After all, there is noone perfect. And that’s right, there isn’t. There are plenty of people working, developing, coding etc, who aren’t in physical/mental health, and who aren’t good at relationships. That’s the way it is. None of us are perfect at any of these things.

   But that’s not the point. In this specific instance, a development team, I believe that developing a healthy relationship amongst the team is the first key element to a strong development team. It continues through everything, because it won’t happen overnight, and probably not for many months. But it’s vital. I want to work with a team where I can be able to trust the people I’m working with. Where I know the manager is looking out for my interests, as well as that of the team. Where we can know that everyone’s ideas are valued, and where we can be chastised with some form of graciousness.

   So my thinking is that the first Motivation is that of relationships.

   This is true if you work alone too. I began my Dev life on my own, for a few years. It was through forums, emails, phonecalls, and just talking to people.

Of course, this is all conjecture. I have yet to reach ten years in Development, I’ve no problem being labelled a newb.

It’s important for us to think about these things, because if I get to the end of my life, and can remember relationships rather than how much money I made, then I’ll be happy.

This isn’t discounting the practical methods of maintaining enthusiasm, and of project management, etc etc. It’s just looking at one particularly important aspect. One which, as above said, I think is vital. Foundational.

Thanks for stopping by.