Info

You are currently browsing the archives for the software engineering category.

March 2010
M T W T F S S
« Feb    
1234567
891011121314
15161718192021
22232425262728
293031  
Links

Archive for the software engineering Category

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.

 

More Side Effects That Become Features

In a prior post, I described an example of a side effect of a feature that our users came to rely on as a feature in its own right.

While reading Raymond Chen’s The Old New Thing: Practical Development Throughout the Evolution of Windows, I came across what I consider the mother of such side effects. In an essay entitled “The hunt for a faster syscall trap”, Raymond describes how an Intel representative was perplexed when a Windows engineer requested speeding up the fault when an invalid instruction is executed. This would seem to imply that the Windows code was buggy in some sort of way. The story goes on to relate that executing an invalid instruction was intentional - as a way to get into the CPU kernel mode.

A version of the essay can be found online here.

 

Hanselminutes - Test Driven Development is Design - The Last Word on TDD

In show 146 of Hanselminutes, Scott interviews agile coach Scott Bellware.

It is an interesting conversation about whether test driven development is a misnomer, the misuse of the word testability, test smells, etc. A valuable conversation for testers to consider when discussing ways to improve the quality of a product. (Especially if someone asserts that additional testing is not required since "we use test driven development".)

 

FDD - Interview with Jeff DeLuca

Feature Driven Development (FDD) is one of the agile methods I think does not get enough attention. In particular, the principles of FDD - as they impact project management -are very useful in agile and non-agile environments. The book that I used to learn about FDD is A Practical Guide to Feature-Driven Development by by Stephen R. Palmer and John M. Felsing. This book has a good description of FDD but is weighed down with a specific modeling approach.

Recently, Software Engineering Radio had an interview with Jeff DeLuca, one of the creators of feature driven development. I found it to be a good introduction to the topic. However, for a practitioner of FDD there will be nothing new here.

 

MSDN Tester Center

I came across a reference to a new online testing resource - MSDN Tester Center located at http://www.msdn.com/testercenter. The site is fairly new but I think it shows promise, especially for people new to the software testing field.

In his introduction to the site, James Whittaker says that one of the purposes of the site is to spread the testing knowledge used internally at Microsoft - especially from those people who do not necessarily speak at conferences or write papers. Having met many talented testers from Microsoft, I think this is a great idea.

As far as content, it is still pretty light - about 4 papers, a dozen videos (each about 5 minutes long) and links to a couple of blogs. But it is new and I like the intent. I will definitely be keeping an eye on it.

 

Agile Practices that Tend to be Problematic

As I have mentioned before, I attended a breakfast talk by Steve McConnell (http://www.construx.com) entitled “Legacy of Agile Software Development”. During the talk, Steve skipped over the section of the slides labeled “Agile Practices That Tend to be Problematic”. I grabbed the slides after the presentation to see what he had to say.

Note: Steve is not necessarily saying these are bad — just that the teams his company has evaluated, these practices have not provided the value that they promise.

 

  • System Metaphor - Least understood practice
  • On-Site Customer - Difficult to achieve
  • Collective Code Ownership - Uneven code quality and sometimes results in lack of ownership.
  • Pair Programming - Sweet spot between junior and senior programmer
  • Refactoring - Good practice whose name is used to cover up bad behavior

Creating Opportunities to Incorporate Change

I attended a breakfast presentation by Steve McConnell (http://www.construx.com) entitled “Legacy of Agile Software Development”. A phrase that caught my attention was “creating opportunities to incorporate change”.

As we all know, The Agile Manifesto (http://agilemanifesto.org/) states valuing “responding to change over following a plan”. Steve’s presentation summarizing agile values had “responding to change” struck out and replaced with “creating opportunities to incorporate change. This struck a chord with me. I have seen many teams that call themselves agile (although I would argue that they were not…) who were resistant to responding to customer requests. Usually, they delay the request stating some rule of the methodology they are following. Almost always, the methodology would allow them to respond to the change — “create the opportunity to incorporate change” — yet the team resists. You can lead a horse to water but can’t make it drink.

 

PRISE - PRocess Improvement and Software Engineering (alpha)

I came across a reference to a Google custom search engine focused on process improvement and software engineering created by Gupta Boda.

PRISE - PRocess Improvement and Software Engineering (alpha)

|