Practicing Earl - All Comments

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

Distributed Agile

Distributed Agile — Tue, 22 Jan 2008 12:55:51 GMT

Pingback from Distributed Agile

» Distributed Agile

» Distributed Agile — Tue, 22 Jan 2008 11:24:17 GMT

Pingback from » Distributed Agile

re: Beyond Functional

Earl Beede — Wed, 07 Nov 2007 12:57:37 GMT

Hi Steve,

I am promoting more focus on non-functional requirements from the start. Most of our techniques focus on functional requirements. I currently believe that at the customer level, there are probably less than 20 critical non-functional requirements that will drive 95% of their acceptance of the product. That is what we need to focus on, not the hundreds of detail functional steps.

re: Beyond Functional

slane — Sun, 04 Nov 2007 16:18:41 GMT

Hi Earl:

Interesting post. I know there's often a humorous edge to your posts, and I thought I'd dig a little and try to extract some guidance as well. It seems like you're drawing attention to the way that requirements can lead straight down into design -- going along that continuum from what to how. So the user story that says "As as user, I can get paid by the system" would fall into the requirements area, but "setting the paid flag" is clearly design.

So one piece of guidance I hear here is to keep your requirements firmly in the real of the "what", and leave the "how" for technical or architecture notes.

But you also seem to address the overall issues of requirements "weight". I know from experience that my customers don't read long requirements docs. And I have learned from experience that neither do my developers :-) Our tech teams find big prose documents boring and unwieldy. They can't find the data they need.

So Earl, are you also advocating an overall lighter approach to requirements, where possible? That something like the agile "iceberg" or "backlog" list, with associated tests, is often the "right weight"? (Clearly, a project with higher criticality, health-critical, regulated etc., will need more "ceremony" and hence probably more formal requirements).

Finally, great point on elicitation of "non-functional" requirements. In our practice, we have a questionnaire that we use as an interview guide to elicit customer expectations in the areas of quality, performance, graphic design, accessibility, and few others germane to our project mix, and that's been a good tool for us.

Regards,

Steve

re: Quality Time

Stephen — Wed, 03 Oct 2007 20:41:39 GMT

Quality can be defined much more broadly than by defects. For example, an application that is user entry intensive may be higher quality if a mouse click can be omitted through the use of a default entry box. It worked without it. There weren't any defects in the code. The design was OK. There may be perceived increased quality if more users can use the same server at a time, or more applications can use the same database server, etc. These are efficiency quality issues. And, there may be optimization vs. maintainability trades that must be made.

Often, when the programmer is given a fixed, arbitrary, deadline, the programmer, in the absence of other input, makes many of these decisions. And rightly so. All nontrivial programs can all be improved. You might get an architect to make such decisions, but it would take longer to communicate these 'requirements' to the developer, and they'd be wrong anyway.

Fred Brooks (20th anniversary of Mythical Man Month) advocates development by starting with a running skeleton, and adding functionality as the application grows. The advantage is that one can ship the product at nearly any time, and it won't hurt anyone. But, one could easily say that the more effort that is expended, the better the product. For many, there is a psychological boost to constantly modify something that works.

re: Doing Justice to V&V

Kevin Haines — Mon, 24 Sep 2007 23:47:30 GMT

If it wasn't the original source, then CMM/CMMI would be a major force behind the use of the terms V&V in software development today. So Earl, I think a visit to the CMU campus should be on your list of things to do.

Like others, I find it near impossible to remember which is which. Ultimately, I find myself not caring which word it is, but being interested in the concept it is trying to instill. An analogy I once heard was that of building a house: "Did you build the right thing?" translates to "did you build the house the customer wanted? Is there the right number of bedrooms, and are they where they were supposed to be?". "Did you build it right?" translates to "does the building conform to local and federal building regulations? Was the electrical and plumbing work done by qualified people?".

Another common problem I have observed is the simple Validation=Testing, Verification=Peer Review. Alas it is not that simple, and some validation "did we build what the customer wanted?" can only be confirmed via static anaylsis (say a code review), and some verification "did we build it right?" can only really be confirmed through execution - static analysis may not be adequate.

In the end, the thing that really matters is what the CUSTOMER wants/needs. Unless there are specific design constraints specified as actual requirements, should we even care about design confirmation (beyond that the design will satisfy all the requirements)? In that sense, you could argue that verification as defined by the CMMI "...to ensure that selected work products meet their specified requirements" is largely redundant.

I believe both testing and peer reviews are very important tools to producing good quality software, but am far from convinced about the V&V breakdown.

re: Worst Companies to Work For, Part All

Jack Smith — Fri, 21 Sep 2007 05:28:51 GMT

DCM a call center based in Brooklyn and Manhattan is one of the worse places to work.

The salary is minimun wage, the commision structue is based on a "wim".

The managment staff walk around looking like zombies.

The head manager treats the adults like children

constantly screaming things like sit down, get up, stop talking, move you seat, don't ask for help from a co-worker.

It is an awful place to work.

There is not recognirion for being productive and reaching the sales goal.

The senior manager only gets worried at the end of the week becuase if the goal isn't met there are no bonuses for management.

Therefore, managment then breaks all rules, in order to get to goal forcing representives to switch from one campaign or another. They offer $1.00 bonuses for anyone during the first hour who sells $300-$600

in subsciptions.

If ever there was a hostile work enviorment DCM is it!

re: Late Expectations

David Harper — Thu, 06 Sep 2007 12:08:35 GMT

You may be in the minority but you certainly aren't alone. One of my pet peeves is people that think being late to a meeting is acceptable. If being late becomes acceptable and gets ingrained into your culture then its not just meeting that are late. Everything becomes late and you find yourself waiting when you could just get on and do it.

re: Late Expectations

David Clayworth — Wed, 22 Aug 2007 21:00:55 GMT

The trouble with the attitude of "I arrive late so that I can get more done" is that it descends into a lateness war. As soon as everyone else you are supposed to be meeting works out that you are trying to maximise your efficiency by arriving late (or by not leaving enough time to be sure you'll be one time) then they also start to arrive late after all why should they suffer an efficiency loss to keep your efficiency high? Of course you respond by being later, and so on.

re: Late Expectations

Jason Bucata — Tue, 21 Aug 2007 18:18:35 GMT

I think it might come down to efficiency. We're so busy that we're scheduled back-to-back, and we can't help but be late. As Tom DeMarco's book _Slack_, and Goldratt's _The Goal_, and many other books, have pointed out, if unpredictable demands are made on your time, you either need to have extra unscheduled time as a buffer to use just in case, or something else won't get done (as you pointed out). But having extra unscheduled buffer time effectively means waste: That 45 minutes you spent at the airport because you got there early is 45 minutes that could have had yet another meeting crammed into it. (Whether the meeting itself would have been a waste is another story...) Who can afford the extravagance of arriving early? Cutting slack time is a calculated risk, especially if the costs of arriving late due to unforseen problems, times the risk of any such problems, are outweighed by the benefits of getting a little more work done. If you manage to "externalize" the costs of your lateness (it hurts those you meet with but not you), then so much the better. Thus pressure becomes habit, and habit becomes culture...

re: Doing Justice to V&V

brucehenry — Mon, 20 Aug 2007 03:29:56 GMT

I am SO with you on the V&V thing. Which one am I doing now? How should I write the email to make it clear? Will the person on the other end understand why we're doing verifi... er... validation on their requirements. Wait... maybe we're verifying that these are actually their requirements.

Gahh!!

To add yet ANOTHER "verification" into the mix... My personal pet peeve along these lines it the use of the term "regression" when talking about bugs. Yes, there is such a thing as regression. But when most testers say that they "have a bunch of bugs to regress", what they mean is that they "have a bunch of bug fixes to verify".

Drives me friggen crazy.

re: Doing Justice to V&V

Kevin — Fri, 10 Aug 2007 20:00:16 GMT

"Very truly I tell you, vultures will think it vain to feed on the bits left. Victory is ours."

Change "bits" to "victuals" and verily, your very venomous and vigorous diatribe against the vampires of V&V will succeed.

On a more serious note, the closest I have come to a successful definition is to say "You validate requirements and verify specifications."

Now, if only I knew the difference between a requirement and a specificaiton.

re: Worst Companies to Work For, Part All

Maksym Shostak — Thu, 02 Aug 2007 18:45:06 GMT

I'd like to add some items in your short list, Earl:

- your manager calls every your idea as nonsense, and they become approved by practice later (but he continues to act the same way);

- your manager does not know such terms as application architecture/design;

- you work at cubical office with 50 employees, sitting on uncomfortable chair;

- extra noisy repairing is going on the other side of the wall, or there are English studies;

- system administrators decides what programing tools you (developer) need to use, what version of MSDN...

That's life in outsourcing.

What do companies outsourced they software projects earn?..

re: Doing Justice to V&V

Mike Ramm — Mon, 30 Jul 2007 15:24:41 GMT

Earl, count me in for doing the justice, too!

Can you imagine how much more difficult it is to distinguish between Validation and Verification for people whose native language is not English?

I would propose to make a contest for defining better terms. We just have to propose some large volume of beer and we'll have a lot of participant :-)