Structured, yes or no?
-
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements. However, there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month. I'm a loner programmer myself and I've always planned my projects by tasks. Now that I do work with a team I find the Kanban approach works well without all the red tape of scrum. Maybe you and your friend could try Kanban, or your own version.
If you think 'goto' is evil, try writing an Assembly program without JMP.
TNCaver wrote:
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements.
Exactly this. I've even worked in a team where I wasn't allowed to pick up additional work if I finished my work, say, one or two days before the end of the sprint, because "we'll be planning that for the next sprint" :wtf: I'd just sit there and pretend to be working. Coworkers were just finishing up their work for the sprint so they didn't need my help either.
TNCaver wrote:
there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month.
Of course there isn't! However, when a client calls and says "we'd prefer you'd work on tasks A and B rather than what you're doing now" or even "drop everything, we need to do this work ASAP!" there should be room for that. I prefer knowing what I'll be doing the next month (if only because that means I have any work at all), but priorities can shift by the day.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Me too! It's why I also prefer to work alone. It seems that the larger the team the more rigidity is required -- Scrum recommends development teams between three and nine members. Scrum would slow me down.
Yeah, with two or three developers you can usually get away with just winging it. More than three and you'll need some process in place. Well, depending on the people you're dealing with I guess (but more people means more preferences). I think it's easier for people like us to follow some process than it is for people who need a process to not have one.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Working solo you can do however you want but once a second person is added there needs to be some sort of structure. Formal process for two people who know each other, probably not. But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen. I agree with the Kanban suggestion.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
-
Working solo you can do however you want but once a second person is added there needs to be some sort of structure. Formal process for two people who know each other, probably not. But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen. I agree with the Kanban suggestion.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
MarkTJohnson wrote:
But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen.
Yeah, definitely! But for me, they can be just that, conversations. That's exactly how my first employer did it. You fix that form, you write a new one and I'll work on a third. Are we clear? See you next week (or when someone has questions, or actually keep seeing you as we shared an office) :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
TNCaver wrote:
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements.
Exactly this. I've even worked in a team where I wasn't allowed to pick up additional work if I finished my work, say, one or two days before the end of the sprint, because "we'll be planning that for the next sprint" :wtf: I'd just sit there and pretend to be working. Coworkers were just finishing up their work for the sprint so they didn't need my help either.
TNCaver wrote:
there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month.
Of course there isn't! However, when a client calls and says "we'd prefer you'd work on tasks A and B rather than what you're doing now" or even "drop everything, we need to do this work ASAP!" there should be room for that. I prefer knowing what I'll be doing the next month (if only because that means I have any work at all), but priorities can shift by the day.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
And that's always been the case. Priorities change. I don't know what the "official" Kanban approach to that is, but we shift tasks between the "doing" and the "backlog" and the "on hold" statuses quite often because of shifting priorities. It doesn't mean you can't plan your day, it just means that sometimes you change your plans.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Waterfall: "We can't do that until the next release in around a year" With Scrum: "We can't do that until the next sprint in a few weeks" That is why you will find people saying Scrum gives flexibility. It all depends on where you started from. So yes, people who says "Scrum brings flexibility" are completely right. Just as the people who says "Scrum is making the process too rigid" are completely right. Understand what the methodologies tries to solve - then understand your own processes (and the problems with it). Then you can choose the right methodology for your team. Only consultants think the same process is the answer to every situation (and strangely, it is always the one where they can offer you "services"). Personally my productivity can be pretty much killed by switching priority daily (or multiple times a day) and I have yet to see a team (let's say 5 people+) that is not more productive if they are allowed to work unobstructed for at least a few days. My personal preference would probably be Kanban - but to be honest our Scrum is already leaning in that direction just because we don't take it too too serious :)
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I think your post is talking about two different things. The first one is process. You don't need guidelines or rules to follow until something bad happens. Then you put something in place to reduce the chances of it happening again, even if working alone. The second one is stability. I would also get annoyed if priorities were constantly changing. It's also not an effective way to work when you often have to drop one thing for another. Returning to where you left off takes time. And if you never return to it, you wasted time on something that wasn't needed. The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.<p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
<em>The fox knows many things, but the hedgehog knows one big thing.</em></p> -
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Structure, with flexibility of course. Without it's all a mess of work hours but with no idea of the direction.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements. However, there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month. I'm a loner programmer myself and I've always planned my projects by tasks. Now that I do work with a team I find the Kanban approach works well without all the red tape of scrum. Maybe you and your friend could try Kanban, or your own version.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
TNCaver wrote:
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements.
Exactly this. I've even worked in a team where I wasn't allowed to pick up additional work if I finished my work, say, one or two days before the end of the sprint, because "we'll be planning that for the next sprint" :wtf: I'd just sit there and pretend to be working. Coworkers were just finishing up their work for the sprint so they didn't need my help either.
TNCaver wrote:
there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month.
Of course there isn't! However, when a client calls and says "we'd prefer you'd work on tasks A and B rather than what you're doing now" or even "drop everything, we need to do this work ASAP!" there should be room for that. I prefer knowing what I'll be doing the next month (if only because that means I have any work at all), but priorities can shift by the day.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
How many clients do you have? Because if I drop whatever I am working on because client "A" think it is important... what about clients "B-Z"? Support cases gets priority (i.e. the product can't do something it should be able to do and it affects their business), but besides that we can't interrupt the team every time a client gets "a good idea".
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Too much structure can cause a lot of useless output. My current example: I'm testing the MVVM Toolkit from MS (which is based on the very popular MVVMLight from Galasoft). When you install the NuGet package of the MVVM Toolkit it comes along with 6 or 7 other packages. And when you create a new build it adds more than 100 files to your debug folder !! MVVMLight from Galasoft did add less than 10 files.
-
Too much structure can cause a lot of useless output. My current example: I'm testing the MVVM Toolkit from MS (which is based on the very popular MVVMLight from Galasoft). When you install the NuGet package of the MVVM Toolkit it comes along with 6 or 7 other packages. And when you create a new build it adds more than 100 files to your debug folder !! MVVMLight from Galasoft did add less than 10 files.
Well, and then there is me: Why on earth would you use a toolkit for MVVM. But I am starting to accept that either: 1) I did not understand MVVM and by accident created something that is way simpler to program 2) A lot of other people are misunderstanding MVVM. I do not care which one it is, as long as those toolkits are kept away from my software. :D
-
I think your post is talking about two different things. The first one is process. You don't need guidelines or rules to follow until something bad happens. Then you put something in place to reduce the chances of it happening again, even if working alone. The second one is stability. I would also get annoyed if priorities were constantly changing. It's also not an effective way to work when you often have to drop one thing for another. Returning to where you left off takes time. And if you never return to it, you wasted time on something that wasn't needed. The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
True, but our churn is dependent on that of our customers. If they have churn, we have it too. The difference is that we're getting paid for it.
Greg Utas wrote:
And if you never return to it, you wasted time on something that wasn't needed.
I've been hearing this a lot too. Frankly, I don't really care. It's nice when customers use your software, but if they don't, they don't. As long as they pay for it it's not my time that was wasted, but their money.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
How many clients do you have? Because if I drop whatever I am working on because client "A" think it is important... what about clients "B-Z"? Support cases gets priority (i.e. the product can't do something it should be able to do and it affects their business), but besides that we can't interrupt the team every time a client gets "a good idea".
A couple, but sometimes it's like that. Last month, I had months of work ahead of me, but someone quit his job and months of work kind of evaporated and priorities for this customer changed quite a bit. Yesterday I had a call with the customer and we're now going to pick up a new project while postponing the previous one. So, I now have weeks of work for this client alone, while yesterday I had none, while last month I had months (talk about churn) :doh: Of course, that resulted in other customers getting more priority with their changes. Meanwhile, another customer called this morning, his reporting didn't work, took me half a day to fix. Of course I'm not doing everything ASAP, but when a client calls it usually has to be scheduled in later this week, or at least somewhere this month.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
And that's always been the case. Priorities change. I don't know what the "official" Kanban approach to that is, but we shift tasks between the "doing" and the "backlog" and the "on hold" statuses quite often because of shifting priorities. It doesn't mean you can't plan your day, it just means that sometimes you change your plans.
If you think 'goto' is evil, try writing an Assembly program without JMP.
TNCaver wrote:
it just means that sometimes you change your plans.
And sometimes multiple times a day :laugh: Maybe this is also because I'm alone working on multiple projects? I guess when you're in a team people have their own clients and projects and maybe there's a bit more stability.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Try something like a Trello task board. If your project is hosted on GitHub, there's a Trello add-in that will allow comments during commits to become tasks. Here's a sample board New Requests Requests being worked Requests being tested Requests completed This will give both of you the ability to see what's in queue and give your friend the structure he needs.
-
Greg Utas wrote:
The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
True, but our churn is dependent on that of our customers. If they have churn, we have it too. The difference is that we're getting paid for it.
Greg Utas wrote:
And if you never return to it, you wasted time on something that wasn't needed.
I've been hearing this a lot too. Frankly, I don't really care. It's nice when customers use your software, but if they don't, they don't. As long as they pay for it it's not my time that was wasted, but their money.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I can see why you wouldn't care if the customer is paying anyway. It's probably a personality thing. Like your colleague, I don't like being yanked around in one direction, then another. I would tell the customer that churn has a cost and suggest that we work together to better determine the requirements in advance. If they didn't want to do that, OK, they're the customer. But not one that I'd gladly take on again.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
When working alone, do whatever you feel comfortable with. I suspect that even then, you impose some structure on your work. When working with someone else, some structure is essential. This is necessary so you can coordinate your work - for example if your team member is designing the UI, you don't want to have him/her sitting around waiting for you to implement & test it while you write the data access layer. This does not mean that you need to implement all the requirements of the American DoD. :omg: :) As always, YMMV.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Greg Utas wrote:
The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
True, but our churn is dependent on that of our customers. If they have churn, we have it too. The difference is that we're getting paid for it.
Greg Utas wrote:
And if you never return to it, you wasted time on something that wasn't needed.
I've been hearing this a lot too. Frankly, I don't really care. It's nice when customers use your software, but if they don't, they don't. As long as they pay for it it's not my time that was wasted, but their money.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I beg to differ. Money is not the only reason I write code. Another reason is the satisfaction of knowing that people find it useful and are using it. Basically, I'm happy when my client are happy with what they paid for. This is also a good way to ensure repeat business.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
