Info

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

September 2010
M T W T F S S
« Aug    
 12345
6789101112
13141516171819
20212223242526
27282930  
Links

Archive for the software engineering Category

Multicore and Multithreaded Programming Links from July 2010 SW Engineering Notes

The following links were published in the July 2010 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was Multicore and Multithreaded Programming.

 

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

 

Reference: S.O.L.I.D. Principles Overview

This post is meant to capture Robert Martin’s S.O.L.I.D. principles (see The Principles of OOD for one of Martin’s original presentation of these items) and some related links. S.O.L.I.D. is an acronym of design principles for object oriented development.

The acronym stands for:

  • SRP: Single Responsibility Principle
  • OCP: Open Closed Principle
  • LSP: Liskov Substitution Principle
  • ISP: Interface Segregation Principle
  • DIP: Dependency Inversion Principle

Here is a list of sites to learn more:
The Principles of OOD- Robert Martin
Pablo’s Topic of the Month - March: SOLID Principles
Getting a SOLID start
dave^2 - An introduction to the SOLID principles of OO design

 

Jason Baker’s Myths About Code Comments

Jason Baker wrote Myths About Code Comments. I like posts like this - they get me thinking about the assumptions I make in my day to day work.

In short, Jason says the following are myths:

  1. Comments are free
  2. Comments make code more readable
  3. You should comment every function, method, class, and module
  4. Code must always be "self documenting"

In particular, I think the first and second points are intimately related. Anything that goes into a product - documentation, code, comments, tests, etc. - is never free. Anything that goes into a product incurs not only the cost of initially creating but also the ongoing cost to keep up to date. If you avoid the ongoing cost by not keeping all items up to date, the result is that the code and the supplementary material diverge - which leads to the myth that comments make code more readable.

 

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