Practicing Earl - All Comments

Usability Collateral Damage – Practicing Earl | DevBlogr

Usability Collateral Damage – Practicing Earl | DevBlogr — Fri, 11 Dec 2009 21:42:31 GMT

Pingback from Usability Collateral Damage – Practicing Earl | DevBlogr

Twitter Trackbacks for Fail Yet Succeed? - Practicing Earl [construx.com] on Topsy.com

Fri, 18 Sep 2009 03:53:50 GMT

Pingback from Twitter Trackbacks for Fail Yet Succeed? - Practicing Earl [construx.com] on Topsy.com

re: Fail Yet Succeed?

kg2v — Thu, 17 Sep 2009 12:24:22 GMT

It's even MORE complex than that! Not exactly "only" software, but I worked for a company 20+ years ago that made a LOT of money based upon "We built what they asked for" for a LARGE client

Picture the job is "Built this system (including software/firmware) to THIS Spec (100+ pages of spec + acceptance criteria) for a fixed price" (OH, BTW, they only got copies , not the RIGHTS to the design)

My boss at that time was fairly good at looking at the specs, and saying "Ah, this is what they Spec'd, but THIS is probably the hidden 'gotcha' that won't make it work in real life"

We'd bid on the job to make a small amount of $$ on building to the spec - while all the time planning on 'how to deliver what they really want'

Deliver the product, and pass all the tests, get paid, and when they would go to use the product, they would find out it didn't work the way they wanted. They would come running back and say "HELP, it doesn't do what we REALLY wanted" - Guess where the company's REAL profit was made? Rolling out the fix we already knew they were going to need!

Unethical? Maybe, but not as much as you think, for two reasons - if you gave them what they ACTUALLY wanted, you could NOT pass the original spec, and no matter what, you HAD to pass that spec, and two, EVERYONE bid on the Spec, and the client pretty much ONLY took in to account 1)If you could do the work (aka actually had a company to do it) and 2) PRICE - yep, low bidder gets the job

As far as I know, the client STILL makes this mistake, and YOU pay the bill - It's the Federal Government.

They'd come to us and say "we need a hardware and software system that does EXACTLY this, bid on delivering 300 of them" Lots of companies would bid (say) $5000 per item to deliver to the spec (where what they really needed would cost say $6000). We'd bid $4900, get the job, and deliver (making a fairly low profit/breaking even), and 6 months later, they come back asn say "we need this change, how much to make it), we could nicely say "$1300" and make an extra $200 (if you tried too hard, they would just cancel the whole thing)

re: Space Cadet

Steve McConnell — Fri, 04 Sep 2009 16:54:03 GMT

I believe the They/We distinction is not a good generalization of the idea that "If it's required, it's a requirement." For anything after version 1, the behavior of the existing system implies a large body of de facto requirements, i.e., in many, many ways the new system is required to act like the old system, regardless of whether the specific behaviors of the old system were originally thought to be "requirements," "design," or just an accident.

There's no "they" in the "must behave like the last version in all important respects" requirement. There are just a lot of required behaviors.

The idea that "anything that's required is a requirement" somehow makes the requirements analysts job superficial or easy is also not right, I think. Part of the requirements analysts job is to determine if when someone says "I want a house with a Home Depot item number 117398 door knob" whether that's a real requirement (ala "the house I grew up in had that exact door knob and I want that exact door knob on my house") or whether it's a vague desire masquerading as a specific requirement ("I was in Home Depot one time and saw a sign that this door knob had excellent security features, and I want the best possible security features").

Another way of stating this is, There are no requirements that are theoretically "off limits" to customers. If the customer truly wants something, even if it seems like design to a developer, then it's a requirement. But there are lots of statements that customers might initially present as "requirements" that won't turn out to be real requirements once you understand what they're really asking for.

I like the definition of quality as "conformance to requirements, stated and *implied*." To achieve a quality system, you have to discover not just the stated requirements but dig deep enough to discover what requirements are really implied.

What Marketing Requirements Look Like

Practicing Earl — Mon, 24 Aug 2009 17:12:37 GMT

I recently went with trepidation into a class with Pragmatic Marketing called “ Requirements that Work

re: Spirit of Waterfall

mattmcknight — Wed, 24 Jun 2009 16:51:28 GMT

Well, that's not very charitable to the agile zealots, but all zealots are somewhat annoying, so, good show. I think the "agile spirit" comments tend to be referring to the principles and the values expressed in the manifesto, wherein some non-agile process gets relabeled agile. So "Working software over comprehensive documentation" is a value, but the team might be placing a very high level of importance on the documentation. There is documentation in Agile, so you are not going outside of agile practices, but you are putting too much emphasis on the wrong part.

In fact, Agile, as defined by the Agile manifesto is a set of values and principles, not a process. In fact, the very first Agile value is to value "individuals and interactions over processes and tools". A conflict arises when people become obsessed with a particular process, typically scrum, and begin to enforce adherence to that process without a focus on the underlying principles.

I think the waterfall spirit is less about "look before you leap" and more about "act as if everything is knowable" and "CYA". Statements like, "You signed off on those requirements and that's what you're going to get" seem to typify agile thinking.

re: Estimation Does Matter

bigboxshops — Thu, 04 Jun 2009 03:36:14 GMT

good explanation of bad estimation , it is probably very possible to not publish or state an estimate?

www.bigboxshops.com

re: Estimation Does Matter

Earl Beede — Tue, 28 Apr 2009 18:52:17 GMT

Wow, do you think that is even possible? While it is probably very possible to not publish or state an estimate, don't you create a mental estimate regardless?

re: Estimation Does Matter

awiesendanger — Tue, 28 Apr 2009 18:12:39 GMT

Hey Earl, nice explanation of why bad estimation is a problem that affects value. But what about not estimating at all?

Estimation Does Matter

Practicing Earl — Mon, 20 Apr 2009 17:17:46 GMT

Recently, Mark over on the Agile Project Management Yahoo discussion list posted this little remark.

Baby names search - Search for B names

Baby names search - Search for B names — Sun, 29 Mar 2009 02:27:49 GMT

Pingback from Baby names search - Search for B names

How to take a break when programming | Ryan Kohn

How to take a break when programming | Ryan Kohn — Wed, 25 Mar 2009 22:42:59 GMT

Pingback from How to take a break when programming | Ryan Kohn

Maccherone » Visibility -> Retrospection -> Adaptation

Maccherone » Visibility -> Retrospection -> Adaptation — Fri, 06 Mar 2009 20:18:00 GMT

Pingback from Maccherone » Visibility -> Retrospection -> Adaptation

Baby names search - Search for Moen

Baby names search - Search for Moen — Sat, 27 Dec 2008 06:46:11 GMT

Pingback from Baby names search - Search for Moen

Function vs. Non-Function and Weakness Assessment | the toe of webdev

Function vs. Non-Function and Weakness Assessment | the toe of webdev — Sun, 28 Sep 2008 09:42:47 GMT

Pingback from Function vs. Non-Function and Weakness Assessment | the toe of webdev

Good reads from the web « Computing Life

Good reads from the web « Computing Life — Tue, 23 Sep 2008 10:04:45 GMT

Pingback from Good reads from the web « Computing Life

re: Defining "Done"

Maksym Shostak — Tue, 16 Sep 2008 12:24:21 GMT

Earl, you know, I had "Make it faster" task from

one project manager in the past. The requirement

was to make the build process (by Ant) faster.

When I asked to define how faster, the answer

was "just more faster" :)

I define "done" by intuition :) I think it is important

first - to define "done", and second - to define it right. Better to make wrong decision, then not to make any.

re: Functionality Is Cheap

Earl Beede — Tue, 29 Jul 2008 14:10:38 GMT

Great question. I wonder if others have input. Otherwise, it is a good follow-on topic to write about!

re: Functionality Is Cheap

mperez@nearsoft.com — Mon, 28 Jul 2008 22:14:58 GMT

Great distinction. This could really help guide the discussion we inevitably have with clients ("if you want it it smaller/quicker/etc, it will take longer," "but, this is not a new feature... ").

So, how do we educate the world on this?

Sick Sigma

Sick Sigma — Sat, 12 Jul 2008 20:26:59 GMT

Pingback from Sick Sigma

Sick Sigma

Sick Sigma — Wed, 02 Jul 2008 15:44:51 GMT

Pingback from Sick Sigma

Sick Sigma

Sick Sigma — Fri, 27 Jun 2008 21:45:16 GMT

Pingback from Sick Sigma

software » Blog Archive » B*tch'n and Moen

software » Blog Archive » B*tch'n and Moen — Wed, 23 Apr 2008 17:44:10 GMT

Pingback from software » Blog Archive » B*tch'n and Moen

Global Warming » Giving Up

Global Warming » Giving Up — Sat, 05 Apr 2008 06:39:34 GMT

Pingback from Global Warming » Giving Up

http://forums.construx.com/blogs/earl/archive/2008/01/21/distributed-agile.aspx

http://forums.construx.com/blogs/earl/archive/2008/01/21/distributed-agile.aspx — Wed, 26 Mar 2008 08:53:41 GMT

Pingback from forums.construx.com/.../distributed-agile.aspx