New answers tagged

1

The single best thing you can do is introduce some standards. Everything you say is caused by a mess of "do whatever" appearing in the codebase. Keeping this concept of "add some more cool tech (eg EF migrations...)" will only add to the problem. You need to reduce the scope of maintenance, not increase it. The best way to do that is to start to reduce the ...


4

If it fits, it works. Quite simply, the people who came up with the first version of the equation took a whole bunch of projects and looked at how much effort (in terms of man months or years) was put into the project, and how much time it took to produce the product. And then they fit it to a curve, and thats the numbers that came out of the data. From ...


3

What you have there is version control. I think we can all agree that it is a pretty crappy form of version control, but you at least do have different versions, even if you don't have commit messages. Why throw away that history? From what I can gather from your description, it's a three-line script and a matter of minutes to import that history into a ...


2

If you only have to update/patch/support a single version, then just starting the repository with your last version is a perfectly good idea. Keep a backup of the old versions, just in case, but I'd expect it to be unlikely you'll need it. However, if you have to support multiple versions of your project, I would recommend making a commit per each of the ...


6

I'd say, do not bother with the old snapshots. Commit current state into the repo and start using it as soon as possible. Just backup the old snapshots and in a couple of month you will not even remember they've existed. From experience, when we migrated from CVS to GIT, the old CVS source control was left there for reference, but after a few month nobody ...


3

Tight coupling, lack of testing, these are probably the most common culprits. Basically the issue is just shoddy standards and procedure. Yet if you work in a very large codebase, I would add one common one which can occur even with looser coupling and greater care to testing procedure. The Side Effects of Removing Parasites Codebases evolve against their ...


-1

It's probably best to communicate between applications that reside within your namespace using a BroadcastReceiver


0

Your customers have to pay for your education and training one way or another, otherwise your business is not sustainable in the long run. The questions is whether time spent researching should be specified as hours on the bill, or rather should be covered by a higher hourly rate which finances non-billable hours spent on research and training. I would say ...


1

I normally wouldn't charge if it was blatantly my fault and I was just jerking around, but I'm not business-smart at all. I have found most business-smart people apply this philosophy that clients are paying for their time, and not merely an end result. There are many times in my career where, in retrospect, I regretted not thinking this way. All I thought ...


2

If you hire a lawyer to argue a case for you, and they botch it and lose for you, you still pay their bill. That's how all other professions do. There is no reason why programmers should do otherwise. If the client thinks they paid too much, they won't come back to you. Keeping them as a repeat customer is the only sane reason for not billing for all hours ...


4

I look at it this way: at the end of the day, it's your call what you charge. There are many variables like how happy you want the client, the existing relationship, your sales skills, etc... we're all familiar with them. What you're ultimately providing the client, and what they really want, is value. What value did you give the client and what's the ...



Top 50 recent answers are included