Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re:Simple methodology (Score 1) 347

How could it have "passed all its tests" if it wasn't connected to the rest of the system? It's hard to do agile without continuous integration; doesn't surprise me it was a mess. But integration blowups are the norm in my experience on waterfall projects - they're the main thing that leads to "the first 90% of the project, then the second 90% of the project".

But the primary win from agile is in avoiding throw-away work. You always work next on what's the most likely to survive unchanged, you only do the design work you need to write the code that you're going to work on (which often includes the entire high-level architecture for the first line of code, but still), you only document what you've actually done, and so on. Bridge specifications are unlikely to change after the project was funded. I've done sever 18-month waterfall software projects, and never seen one where more than half of what we thought the project was at the beginning was what we delivered at the end. Make it cheap and easy to change the requirements, because the requirement are going to change, and there's no holding back the tide.

Comment Re:.dev (Score 5, Informative) 185

I think .dev should be like example.com: not able to register so DEVELOPERS (re: NOT GOOGLE) can use like, [mydomain].dev to develop, and not have to create wonky local host names.

RFC 2606 reserves 4 TLDs for this purpose: .test .example .invalid .localhost

I've always used .test for domains for QA/test deployments. It also reserves the example.* second level domain name across all TLDs.

I think there are some other reserved TLDs, including ".xy" and some 63-character name that was something like "sixtythreecharacterdomainnamefortestingpurposes" , but I can't find the RFC. Anyone?

Comment Re:Simple methodology (Score 1) 347

The person who "owns" the project. Generally they run it, as it's their ass in the fire.

Ah, well, the ideal anyway for Agile is that's the team.

don't believe I've been on an agile project where PMs did not run the scrums.

Wait, what? OK, by "PM" do you mean Product Manager (guy who's constantly visiting customers, or at least on the phone with them, often has an MBA), or a Project Manager (useless wanker). I've never seen Agile done well at companies that still employed the latter (but then I've never done consulting).

I always agree to a core scope that must be met, and then the nice to haves that are negotiable. This approach leads me to a much better success rate, happier clients, and successful projects

I agree that's the secret.

The agile approach has left disaster and/or disappointment everywhere I've seen it. Because the world is promised, and only some is delivered, on "successful" projects

Sounds like "Scrum consultants" selling snake oil, then moving on to the next victims ahead of the angry mob. Agile achieves 3 things if done right: much less throw-away work, early integration for fewer last-minute surprises, and a dev team who's emotionally committed to the dates, rather than hating management for the dates and wanting to hurt them in return. Those can make a pretty significant difference, but if you have intelligent, non-dickish management to begin with then only the first really changes (and if management is bad enough, nothing gets better).

Comment Re:Simple methodology (Score 1) 347

What does "running the project" mean here?

Agile projects need a Product Owner (and that's usually where projects diverge the most from the ideal - I've never met a PM who actually attended scrums), to stack rank work and answer team questions about requirements. But he doesn't "run the project". It's often handy to have a formal Scrum Master, if you're doing scrum, but he's doesn't "run the project".

Everywhere I've been, management "ran the project", just as with waterfall - they agreed on the delivery date and the staffing. One point of Agile is that the scope falls off, rather than the date slipping, but that's not all that different from tradition.

Comment Re:Simple methodology (Score 1) 347

Manager: "Get on with it! Work whatever hours you have to, we're late now!" ... instead of:

That actually happened to me once! It was a Thursday. By Monday I had a written offer for my next job and gave notice. That's the one nice thing about Silly Valley - bosses are as interchangeable as developers, so you're free to find one who's not a moron.

Of course, if you're stuck, you just triple (minimum) all your estimates, Scotty style.

Comment Re:Simple methodology (Score 1) 347

That first 6 weeks is the easy stuff. The REALLY easy stuff. The last 20 weeks is the hard stuff, if somebody cares about polish, fit, and finish.

Not if you're good at your job. It's only if you suck at estimation that you have "the first 90%, then the second 90%". If you know from experience how software projects go, that's what all your estimates are based on. Only a junior engineer will think "this will take me 3 weeks to code, so I'll tell my boss 4 weeks just to be safe"! Coding is ~1/3rd of a typical software project (and less for environments with inflexible auditing or external testing requirements).

Of course, that doesn't stop managers from saying "ship it" the first time they see anything work. Heck, some will say "ship it" when the see the mock-up. But you have to manage those guys, or switch jobs.

Comment Re:Simple methodology (Score 2) 347

The first and foremost requirement is that when sales/marketing sales that they want 100 features in the product and there is no way that we can doo all 100 features, we have to be able to prioritize them

Yes, that's exactly how all Agile development works. Did that not work out for you?

Now, please tell me how Agile is going to tell me how much effort is going to be required to complete a particular project when the whole Agile approach is to start coding and figure it out as we go?

That's not quite Agile - you need enough of a plan and a design to know WTF you're doing before you start, you just don't need an in-depth design of stuff you won't even touch for 6 months. But you know what the components are, and about how big each one will be, at least relative to each other, and you know where the dependencies are. So how do you know ho long it will take? You measure you're progress! When you know you're 20% done, and it took a month, then you know it's a 5-month project. I've been within 5% on estimates for large projects, even as they changed significantly over the course of the project we could be that accurate on updated estimates.

OK, here is another requirement. We need to put together timelines because Engineering doesn't operate in a vacuum. We are part of a company with many parts all of which have to be coordinated

Schedule, scope, resources, quality. One of these four must be give when estimates are wrong or changes creep in. You have to pick one, or it will be quality be default. Agile is just saying "OK, so scope is what gives".

I've been doing agile-style development since before that word was coined, and I've never failed to deliver the must-haves on time for a project. Really. Honestly goes a long way.

The big problem with Agile is that it was created by Engineers in a vacuum who failed to recognize their responsibilities to the rest of the Company

So, where'd you get your MBA from?

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

You can't really give a good estimate up front on most projects, because even if the requirements are well defined (and they rarely are) they will change.

That's all OK. That's the whole point of Agile, if you ignore the Agile BS that consultants sell. You can quickly do coarse-grained task breakdowns (say, to 2-week tasks) to get a reasonable estimate of the work as you currently understand it: that estimate is generally within a factor of 2, if the requirements don't change, so you can at least see if you have 1/3rd the staff you need or something way off.

Then you measure real progress against that first-take estimate. Usually by about 6 weeks in on a team-sized project, you'll have the real multiplier. "We thought the first set of tasks were 20 programmer-weeks, but really as we understood it it was 30", and multiplying that initial "6 months" estimate by that measured 1.5 multiplier is a damn good estimation method. And it only gets better as work goes on. I can reliably give fairly accurate estimates from project completion now, on Agile projects, by the time we're about 1/3rd of the way done (and that's so much better than some teams are used to that it seems like magic).

Selling that all properly to management is a different thing, but that's a whole job skill that any senior engineer just needs to have. Just like showing management the cost of each requirements change, as well as the skill to minimize that cost of change (which is the real point of Agile- the rest is hype).

Comment Re: Not surprised (Score 1) 311

You can go to StormFront for example. I doubt you'll be constrained by silly things like civility or compassion there.

I really doubt they're interested in discussion of their issues. There are plenty of echo chambers on the internet, for any viewpoint. But a site where people can discuss both sides even of issues where one side is very unpopular? That's a beautiful thing.

Comment Re: Not surprised (Score 1) 311

Shadow cabal? It's all in the open now. Reddit and 4chan now ban anyone trying to disagree with "SJW hot topics", e.g. gamergate. 4chan even had a large-scale mod purge. For forums that started on the premise of open, uncensored discussion (especially 4chan), that's kind of a dick move. It's their forums, and they can do whatever, but still: dick move.

Slashdot too, though it's really understandable since they officially sold out (and Taco was really professional about it all). There's no way Dice is going to host GNAA trolls and the like.

I'm not sure where you're coming from with "I've got mine"? I'd like to have a forum where (legal) discussion was uncensored, but they do seem to go though an uncensored -> popular -> censored -> unpopular arc.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...