Richard Andrew x64 wrote:

But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method?

I've worked projects in traditional "up front design"/waterfall and agile management. The right choice depends on the project and the players. I've found that the following are relevant: - UFD requires that the entire project is designed and planned before the software development starts. This can help with budgeting and well defined tasks. The project is finished when the development and testing is done. This works best with a relatively short time span (several months). - A UFD design document is "the design" and needs to be completely thought out. - A UFD project generally describes one version of the product. - An Agile design document is needed, and needs to define high level features but should not describe granular details. - UFD invites project management dysfunction such as feature creep, "this isn't what we want" and is very difficult to change one or two steps in "the plan". - Agile accommodates feature creep and invites stakeholder and end user participation if they see that they can change a bad choice into something they want. - Agile projects can comfortably go on for years and span multiple versions of a product. - Agile allows software development at an earlier stage in the project design. You also get a better ad hoc idea of how much effort is required to complete the task. - Agile is harder to budget and justify to upstream managers and bean counters. - UFD generally provides better adherence to features and (sometimes) reliability. - Agile generally provides better UI and general User Experience. - Agile will give you a product that you can start using much sooner, as feature 'x' and 'y' are implemented. - Agile will let you prioritize implementation details, do UI changes or partial redesign or add new features as needed. - As long as you have incoming funding, Agile will give you a better product that more people will like. For a better outcome: - Use UFD to design a rocket lander or navigation computer or hospital ventilator. - Use Agile if you have indecisive users or sales/managers that promise new features that were not planned for. P.S. if your scrum meetings are hours in length, you are doing scrum wrong. This daily meeting should take pla

All good advice here. Nothing else to expect from Griff. I would recommend PLA more than PETG that the site suggests. PLA is considered more of a "beginner" filament vs PETG because it is easy to work with etc... but some of the objections and advantages I think are subtle and a bit over done. PLA is considered more biodegradable for example, but people that have buried things in their gardens for a few years see that the PLA items are still about as robust as the PETG ones. The other differences don't show much contrast between the filament types (ie. on a scale of 1 to 10, a 9.1 and a 9.2). And I disagree completely with the temperature ranges provided. In my experience, PLA prints in the range of 180 to about 250 degrees, PETG 200 to about 260. PETG is much worse at stringing and self-adhesion between layers. Any models with a lot of "action" are much harder with PETG. PETG has more print failures. And colour? Surprisingly I've seen more differences between filament colours (and brand names) than between material type. I have come to the point of printing a temperature tower for each new box of filament, storing it in the box it came in and picking the right print temperature based on what my print model looks like. Something with overhang, sharp edges or flat surfaces would be printed in PLA, something requiring durability or strength would be PETG. Some vendors have something called PLA+ that I am happy with. No idea what it is. I started with PLA, then shifted to PETG later and have built up a considerable library of (mostly) PETG filament. I have become a bit jaded with PETG and am shifting back to PLA. Oh and ... Cheap filament is usually no bargain.

If pigs could fly, just imagine how good their wings would taste! - Harvey

Just sell the Chevy and buy a Tesla and you won't have to mess with any of that mess.

If pigs could fly, just imagine how good their wings would taste! - Harvey

I dislike Git for its gratuitous complexity and penchant for storing many and large files in your work area.

� Forogar � wrote:

if you can't cope with GIT you are in the wrong job.

I'm retired. Oh yeah and I mostly use CVS and SVN.

If pigs could fly, just imagine how good their wings would taste! - Harvey

They wouldn't store the password but a (fixed size, hopefully long enough) hashed version of it. If the hash is shorter than a "really long" password such as yours, then there will be guaranteed collisions. A brute force strategy would find (possibly multiple) valid password(s) that you did not intend. So in one sense, you are correct that they shouldn't care about password length - longer passwords weaken the answer. But that somewhat becomes your problem not theirs. In the big picture, users of that website should be concerned more about the hash length, but users are rarely privy to that info.

If pigs could fly, just imagine how good their wings would taste! - Harvey

Why a PC? Get her a tablet with a touch screen and a detachable keyboard (or attachable depending on how you look at it).

If pigs could fly, just imagine how good their wings would taste! - Harvey

Yeah, speaking of which, does anybody have a running computer that can read a SCSI disk? Asking for a friend.

If pigs could fly, just imagine how good their wings would taste! - Harvey

If you are testing software, my recommendation would be to get 2 test machines: 1. The hottest hopped up laptop with the most modern expensive options, lots of memory and large disks 2. The oldest wimpiest crappy laptop that you support for the software with the smallest memory and disk that are reasonable to use with it. Make sure it has Windows Vista. You'll be seen as the smartest tester in the group.

If pigs could fly, just imagine how good their wings would taste! - Harvey

It sounds to me that you have him by the balls.

If pigs could fly, just imagine how good their wings would taste! - Harvey

How much wind could a windbreaker break if a windbreaker could break wind?

If pigs could fly, just imagine how good their wings would taste! - Harvey

My favorite is B#, also known as C.

If pigs could fly, just imagine how good their wings would taste! - Harvey

That's what she said.

If pigs could fly, just imagine how good their wings would taste! - Harvey

A subroutine is really a function returning void. That is how it is defined and linked in FORTRAN on all the platforms I've used.

If pigs could fly, just imagine how good their wings would taste! - Harvey

It has been said that hindsight is 2020. Thank goodness!

If pigs could fly, just imagine how good their wings would taste! - Harvey

OriginalGriff wrote:

...So ours is called "Dij" as in "short for Digital" because as a kitten he was indeed digital: on (and doing a Wheel of Death round the room) or off (and you could have pulled his whiskers out without him moving). The "G" became a "J" in the spelling so vets wouldn't think his name was "Dig"...

So if you became the owner of a pet that liked peanut butter you'd call him Gif?

If pigs could fly, just imagine how good their wings would taste! - Harvey

Nagy Vilmos wrote:

The ticket has been reopened as "the user doesn't want to change their workflow"...

The solution to this problem is to provide some new functionality that can only be accomplished by following the new workflow.

If pigs could fly, just imagine how good their wings would taste! - Harvey

Marc Clifton wrote:

Unfortunately the cat still observes it, thus collapsing the quantum state into various poop states.

Huh? Oh I see, you're talking about Louisiana, Mississippi and West Virginia.

I'm retired. There's a nap for that... - Harvey

Didn't see that coming.

I'm retired. There's a nap for that... - Harvey

Over the years, I've worked on numerous projects with various project management methodology. Each has its own strengths and weaknesses, and each has a situation where it should never be used. I won't restate the obvious. Agile is an ideal project management method where you might have a stakeholder or manager that has severe ADD and is always chasing rabbits. The rabbits become the project. Feature creep that is deadly in other management methods can be embraced with Agile, usually with good results. If somebody is paying for the development, then why complain? You will tend to create a product that is more what the customer wants (admittedly guided by a subset of end users). If you have a product that is continuously being tested by users, the feedback that you get might be quality input and provide direction for the order ("sequence") that you implement certain tasks and how to create or adjust certain UI features. If you get an informed set of test users, you might get ideas for implementing useful sub-features or workflows that might not have been conceived at the product design stage. With Agile, you tend to have a releasable product sooner and with better end user acceptance. With Agile, management and stakeholders have a more visible window into progress of the project/product. Showing continuous visible progress can have a good job security angle. Agile can be useful when writing a software product used by many people. UI, Web page, tax software, spreadsheet, word processing, technical calculation app, scenario handling, ... Agile should not be used if the objectives are very clear, or deviation is a failure. It should not be used for software projects launching a rocket, calculating orbital mechanics, security tokens, SSL/TLS, financial transactions.

I'm retired. There's a nap for that... - Harvey

That's pretty funny.

I'm retired. There's a nap for that... - Harvey