I may do so at some point in the future, since there seems to be some interest in it. I would want to run anything like that by an attorney first, since I'm fairly certain it does constitute legal advice.

And if I don't want to use a GUI? Seems your steps should still be applicable to the CLI. That being said, you're rewriting history when doing that, and that is considered a huge no-no when using Git, especially when you have a team of developers. You'll have a local branch without the commit you just skipped over, but everyone else will still have that commit in their history, meaning they'll all still have the "bad" code. It's probably fine if you're the sole developer, but it's generally not advised to assume that will always be the case. Methinks I'll not follow your advise on this.

Go a little farther west and you can walk into a 7-11 and walk out with a dozen anonymous phones.

And my comment was about clients making changes to the spec. It doesn't matter how good your estimate is or how perfect your project plan is if the client decides to change the project after work has begun. You can refuse the changes, but they can also refuse to pay. You can give up the job, but hey, you're still not getting paid if you do that. The best hope you have is for the client to understand that their change, no matter how trivial it may seem, means more work for you and, therefore, more cost for them.

Or, to put it another way, go ahead and estimate the cost of that paint job. Then build a project plan for it that holds up in the situation I described. I'll be pricing you against a few local shops who are known for quality work; you high has to be competitive or I'll go elsewhere.

This isn't as much of an issue when your client is internal to the company, but that was clearly not the case in my analogy.

And yet, you still get know-nothings who insist that you're wrong and want to push forward anyway. Thankfully, for the ones I've encountered, money is not an object and they're more than happy to pay for the work to be redone. I had one client try and argue the point and I told them very plainly that their options were to continue the project as originally detailed, take the incomplete work, as-is, or pay for the changes they were requesting. Which option they took is irrelevant, but I'll say the project got done and I got paid.

That doesn't negate the fact that people will still insist on changes, no matter how careful you are in communicating issues you find in their requirements and getting clarification before starting work. You're absolutely right, though; many people don't know how to handle it when it happens.

My example was meant to highlight the fact that a single word change in the spec can mean having to redo work. No matter how easy it is to *undo* the work (in the case of programming, it's often much easier than in my analogy, but this is not always the case), the fact remains that the work must still be redone. Just because my analogy did not include having done work that needs to be kept, subsequent to having done work that needs to be redone, doesn't make my honest curiosity irrelevant; and your response seems to indicate that, save for having planned for that very occurance, it is indeed not possible (and even with planning, only maybe, if you're willing to create a new branch for nearly every commit... and you're lucky).

Honestly, I was hoping you'd tell me it was easy. This is one of those instances where I'd jump for joy while screaming at the top of my lungs "I WAS WRONG! I WAS WRONG! THANK YOU, LORD, I WAS WRONG!" Not that I have a use for it at the moment, but it's come up in the past and I'm sure it'll come up again in the future.

You still end up rewriting code. Version control is great for many things, including rolling back to a previous point in time, but please tell me how to undo something I did last week without rolling back everything I've done since. I'd actually really like an answer to that, with regards to Git, if you've got one.

Well, yes, if a car was a data construct. Way to miss the point.

Or were you going for funny? in that case, yeah I'll grant you that. ;)

You've got a few years on me, actually! I've just spent a little over 4 years working for a guy who's made some real boner mistakes and got to learn form him. :)

I'll drop you an email in the AM, I really should be asleep right now.

I have a project that was due last week that I haven't started on yet. I got the deposit check the day I handed over the SoW, but didn't get the signed SoW back until last week, 6 weeks later. As per the terms of the SoW, I'll reschedule it when I find time.

Most of the delays I encounter are caused by someone else; either the need to refactor someone else's shit code (that I wasn't allowed to review before providing an estimate, of course), delayed approval for the work, delayed access to resources, any number of external forces. Very rarely do I exceed my estimated *hours* for a project unless changes are requested (but then I'm not exceeding the estimate, either, since I make the client either agree to a new estimate or accept a refund of any portion of their deposit not already applied to the hours I've worked), but all too often I find myself completing projects well past their due date because some resource wasn't made available to me until after that date had lapsed.

Fortunately, I foresaw that unforeseen things would happen when drafting the boilerplate language of my SoW and covered all of those cases. I go over the entire SoW with my clients before starting a project and make sure they know what the triggers are for a re-quote, what will cause the project to be delayed, and under what circumstances they're entitled to a refund of any deposit they pay (e.g. if they back out of the project once I've started work, I'm deducting my hours from that). As a result of that, and perhaps a bit of luck, I haven't had any disputes over project scope, budget, or timeline, and the one client I did have back out of a project simply said they no longer had the budget (they were being sued) and told me to hold on to the remainder of their deposit as they'd be back to finish the project after they lawsuit ended, hinting that, even if that didn't happen, the small sum would make no difference going forward (of course, I'm sitting on that money for now, and if they fully back out of the project I'll insist that they either accept the refund or sign a document releasing the funds to me).

That was one thing that really pissed me off when I was working for someone else; I had no control over external interruptions or delays and it was usually the person interrupting and delaying me who was holding me accountable for all of them. I'm not out to scam anyone, but I always felt like I was when dealing with my previous employer.

He may have been able to write more maintainable, more stable, better tested, and altogether cleaner code, given what he asked. Possibly in half of his worst-case estimate of 2 years. In the long run, the crap that needed to be slapped together to get the project "done", in 4x the time he was allotted, will end up costing the company more than giving him what he asked for in order to do it right. You must be an MBA.

Depending on how far along in the project you are, it's reasonable to expect changing a single word in the spec to have a major impact on the project. Consider:

So you do all the prep work, car's primed with a dark primer, black paint is mixed and ready to go, then this change request comes in:

Well, now you've wasted the paint you just tinted black, and you can't paint white on top of dark primer (well, you can, but you need many more coats), so you've got to redo the prep work. That means waiting while the primer fully cures, so you can sand it off properly; otherwise, it'll gum your sandpaper. then re-prime, then you can paint. Assuming you don't see

in the meantime.

That was one word. Yes, one line matters.

The commenter who replied to you pretty much pointed out where you're wrong, so I'm not gonna waste my time. I'll add one bit that he missed, though; the relevant 8 pages are a subset of Title II's 33 pages. Have a nice day.

Okay, let's break that down:

Pretty clear. Rules = code. 8 pages of rules will be codified.

An additional 79 pages of rules that could have been codified won't be. Can they be later? Sure, whether they were in this document or not, they can always be written and voted on later.

Oh, look, more rules they considered, but that didn't make it into the 8 pages that will be codified.

Even more things they talked about that didn't make it into the 8 pages that will be codified.

For reference, to codify means To turn into law.

In short, it's 300+ pages of shit they discussed before arriving at the 8 page subsection of the existing Title II that will apply to internet services. We don't get to see the 8 pages of stuff that does apply, or the 300+ pages of discussion that does not, just yet; however, a reasonable person can probably guess which of the 33 pages of Title II might have made it into the applicable 8 pages.

That said, I wouldn't expect you to have that ability.

Title 2 has been around since 1996. If you don't know what it says, that's on you, not the FCC. All the FCC did was reclassify internet services as common carrier, covered by Title 2; the 300+ pages is an account of their justification for doing so, not 300+ pages of new rules.