Category: requirements

Total 3 Posts

Douglas Crockford – Quality

A coworker pointed me to the following video: Quality Software Development by Yahoo Architect Douglas Crockford (181 MB). The presentation from from the Yahoo 2007 FrontEnd Engineering Summit (March 7-8, 2007).

Below are my notes of the slide titles.

  • The Software Crisis
  • Craft vs Engineering
  • Computer Science has not taught us how to manage software projects
  • Software Construction (Good and Bad Analogy)
  • Nature of Software
  • Programming is Difficult
  • Lack of Metrics
  • Lines of Code – not good
  • Programmers are optimists
  • Programmers do not understand how they spend their time
  • Actual time typing is pretty small
  • Skeptical of anything that requires more keystrokes
  • Programming is a social activity
  • Cost of Innovation
  • Legacy
  • Leaps (of productivity? software capability?)
  • Object Oriented Programming (History)
  • Failed Leaps
  • Software does not have enough self awareness to be afraid of bugs
  • Bugs
  • Snake Oil / Silver Bullets
  • Mythical Man Month (1975)
  • Literate Programming (Knuth)
  • Significant difference in individual ability
  • Surgical Team (Harlan Mills)
  • Incrementalism
  • Beta (Perpetually Unfinished)
  • Application triad (skill, technology, requirements)
  • Feature Cost
  • Code Value
  • Code Quality (Micro and Macro View)
  • Simplest thing to enhance value of codebase – make more readable
  • Yahoo Javascript coding convention
  • Programs are a medium of intentional communications
  • Good architecture – necessary structure to keep from collapsing
  • How do we change a correct program into another correct program?
  • Cruft – “Software Scar Tissue”
  • Causes of Cruft
  • Bloat – “Software Cancer”
  • Insecurity
  • Cruft accumulates -> complexity groups -> progress slows
  • Refactoring
  • Sometimes it is best to start over
  • The pain of the crash
  • The illusion of completion
  • An experienced team can cross that ground again very quickly
  • Conclusion

 

By - On 2010-07-17 - in process improvement, project management, requirements, security, software engineering

Jason Fried of 37Signals – Business of Software 2008

One of the things I love is being able to see presentations from conferences I was unable to attend. A coworker passed on a link to this video (55 minutes) from the Business of Software conference. In the talk, Jason Fried of 37Signals, makes of Ruby on Rails and Basecamp, speaks on many aspects of running a software company and keeping teams working effectively.

Here are some of the slide titles, topics and items Jason discussed:

  • Planning is vastly overrated – no roadmaps, specifications, projections. Get rid of distractions. Functional specification does not reflect reality and leads to an illusion of agreement.
  • Decisions are temporary – optimize for now
  • Red flag words – need, can’t, easy, everybody, nobody. These are the words that cause projects to be late
  • Interruption is the enemy of productivity – the closer the team is physically, the less you get done. Interruption is not collaboration. A fragmented day is not a productive day.
  • Underdoing – target non-consumption
  • Find the right size – imagine the software as a physical item
  • Follow the chefs – what is your cookbook?
  • Always be questioning – Why are we doing this? What problem are we solving? Is this actually useful? Are we adding value? Will this change behavior? Is there an easier way?
  • Give up on hard problems – there is an abundance of easy problems
  • You’re an editor – Curate your product. Say no to more things than you say yes.
  • Work Less
  • Q&A – Starts 28 minutes into the video

An enjoyable video, especially the first half before the Q&A session.

 

By - On 2009-09-07 - in conferences, process improvement, professional development, project management, requirements, software engineering

My Definition of a Requirement

I recently received an invitation to join the Yahoo Requirements Engineering Group. This led me to thinking about my definition of a requirement. I saw a similar definition in a document (it was part of the boilerplate text) delivered by a consultant at a prior position. It was the most useful item in the document… (For the life of me, I cannot remember who the consultant nor firm was.)

Requirement – A testable assertion of a customer’s need.

I like this definition a lot because it is simple and lacks a lot of the technical jargon or background knowledge required for other definitions. The terms are understandable by business users. The one thing I always add when I deliver this definition is that customer is not limited to our external customers – it is inclusive of all our internal customers.

By - On 2006-12-31 - in requirements