Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re: version control (Score 1) 347

by BronsCon (#49154987) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:Simple methodology (Score 1) 347

by BronsCon (#49149145) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:Simple methodology (Score 1) 347

by BronsCon (#49149095) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:version control (Score 1) 347

by BronsCon (#49149039) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:version control (Score 1) 347

by BronsCon (#49148835) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:Simple methodology (Score 4, Interesting) 347

by BronsCon (#49144607) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:Well someone has to do it (Score 2) 347

by BronsCon (#49143045) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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.

Comment: Re:Simple methodology (Score 5, Insightful) 347

by BronsCon (#49142953) Attached to: The Programmers Who Want To Get Rid of Software Estimates
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:

Paint my car black.

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:

Paint my car white.

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

Paint my car forest green.

in the meantime.

That was one word. Yes, one line matters.

Comment: Re:Lots of corporations wanted this badly (Score 1) 623

by BronsCon (#49142401) Attached to: FCC Approves Net Neutrality Rules

The rules are eight pages. However, the details with respect to forbearance, the regulations from which we will not be taking action—that alone is 79 pages. Moreover, sprinkled throughout the document, there are uncodified rules — rules that won’t make it in the code of federal regulations that people will have to comply with in the private sector. On top of that, there are things that aren’t going to be codified, such as the Internet Conduct Standard, where the FCC will essentially say that it has carte blanche to decide which service plans are legitimate and which are not, and the FCC sort of hints at what factors it might consider in making that determination.

Okay, let's break that down:

The rules are eight pages.

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

However, the details with respect to forbearance, the regulations from which we will not be taking action—that alone is 79 pages.

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.

Moreover, sprinkled throughout the document, there are uncodified rules — rules that won’t make it in the code of federal regulations that people will have to comply with in the private sector.

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

On top of that, there are things that aren’t going to be codified, such as the Internet Conduct Standard, where the FCC will essentially say that it has carte blanche to decide which service plans are legitimate and which are not, and the FCC sort of hints at what factors it might consider in making that determination.

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.

What's the difference between a computer salesman and a used car salesman? A used car salesman knows when he's lying.

Working...