Tag Archives: software development

Success factors for quality software development teams

Some notes from a short presentation I gave on building quality software development teams:

  • Effective teams start with good people. A business is not a charity and cannot wait for people to grow into the role required of them. Intelligence and inherent motivation cannot be taught. These and many other aspects must be screened for.
  • But hiring good people is not enough.  Getting the most of a development team requires certain environmental factors. I have organized them into three areas:  internal/motivational, structural/organizational, and interpersonal/communication. Sometimes they will conflict with practical considerations, but we ought to take them consideration whenever possible.

Motivation
  • Instill a sense of professional pride
    • Developers should take part in the technical design
    • Provide interesting, challenging work
    • Developers should own the technical solution
    • Technical architects should be part of the development team
  • Respect the developer time
    • Provide a quiet environment dedicated to development work
    • Buy the best tools for the jobs – powerful computers, large monitors, etc.
  • Reward learning and exploration
    • Take (reasonable) risks with new technologies
    • Schedule time for self-education and information sharing
  • Create a sense of project ownership
    • Delegation “ownership” of functional parts to individual people
    • Assign developers responsibility for follow-up maintenance (don’t just hand it off to a maintenance team)
Structure
  • Hold people accountable for their work:
    • Use a work unit tracking system (TFS, etc)
    • Make task status publicly visible
    • Hold daily stand ups (Scrum)
    • Consider a public scrum board
    • Provide clear project requirements
    • Lean development approach
      • No time-wasting tasks (useless documentation)
      • Isolate developers from unrelated tasks (no business interruptions)
  • Hold high expectations
    • Monitor quality of work with code reviews
    • Regular training & information sharing sessions
    • Consequences for bad work
  • Set well defined deadlines
    • Don’t set arbitrary deadlines, but all work should have a deadline
    • Developers should have input on deadlines for their work units
Team Communication
  • Instill a sense of collective ownership of the project
    • Hold architectural education sessions
  • High-bandwidth communications
    • Entire team should work in physical proximity
  • Make quality visible
    • Use continuous integration and automated testing to provide immediate feedback of quality
    • Developers should fix their own bugs
    • Track quality over time
  • Explicit mentor roles
  • Mentor roles should be explicitly defined
  • Mentoring time should be scheduled into the project

 

Setting up continuous integration with TFS

This is a quick visual guide to setting up continuous integration with TFS 2010.

TFS is used to create build definitions for specific trigger criteria.  After the builds are copied to the drop folder, MS Build calls the MSDeploy publishing service to update the target website.

1: Configure a new TFS build controller and connect it to your TFS team project collection:

 

2: Add a new build definition:

3:  Choose continuous integration build triggers.  I setup up two triggers: one for a rolling build, and one to run every day at 3 AM.

4: Specify the build controller and staging location (build output folder) for the builds

5:  Now you need to copy the builds from the build folder to the web server.  We can do this using MSDeploy.

In the “MS Build Arguments”  field, I put:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:MSDeployServiceURL=http://dailyodin.example.com /p:DeployIISAppPath=”/OdinDaily” /p:CreatePackageOnPublish=False /p:MsDeployPublishMethod=RemoteAgent /p:AllowUntrustedCertificate=True /p:username=MYDOMAINSERVICE_ACCOUNT /p:password=PASSWORD

Note that TFS will run unit tests by default.

(TODO: I need to figure out how to use integrated authentication so I don’t have to save the credentials in plaintext.)

 

Now I need to configure the website on the target server:

6:  Setup the integration web server.  Use the same application path as the DeployIISAppPath above.

7:  Install the web deployment tool 2.0 from http://www.iis.net/download/webdeploy

When you install the tool, make sure the Remote Agent Service is included in the install.

8:  The Remote Agent Service is manual by default.  Change it to automatic.

9:   That should be it.  Now you should be able to “Queue a New Build” or (depending on your build trigger) check in some code and have your website updated!

You should be able to see your builds in TFS by double-clicking on the build definition.  Any successful or failed builds will show up here:

 

Closing Notes:

The TFS server, build server, build drop location, and web server can all be separate machines.  Using web deployment, we can locate the web server anywhere on the Internet, so we can use this method for one-click deployment to production as well.  However, we probably don’t want to save the credentials for the production server in the build definition to avoid accidental one-click deployment to live servers!

 

Update:

If you just want to deploy the build output to a folder or file share, you can modify the build process template. Add a CopyDirectory to the step after RunOnAgent.  (Source)

 

10 simple questions to evaluate a software development organization

All credit and inspiration for the questions below goes to Joel Spolsky’s The Joel Test and Bill Tudor’s 2010 update.

My version differs in two aspects:  First, has just ten questions ordered from highest to lowest priority (in my personal opinion).  Second, in addition to yes/no questions, it asks open-ended questions intended to give more informative answers in an interview or an analysis of a software team.

  1. Do you use source control? What kind?  What are the requirements/checks to check in code (assignment to work items, unit tests, peer review, etc)?
  2. Do you use a bug database to track all issues? How do you track progress and manage change?
  3. Do you use the best tools money can buy? For example: MSDN/Apple Dev accounts, dual monitors, and powerful workstations.
  4. Do you have a dedicated QA team? Are they involved in the requirement/release management process?
  5. Do you fix bugs and write new code at the same time? How do you balance the two?
  6. Do programmers have quiet working conditions and team meeting rooms?  Describe them.
  7. Do you solicit feedback from end users or customers during the development process?  How is it used?
  8. Do you do a daily build? Do your builds include automated unit tests?
  9. Do you have a requirements management system? Is it integrated with your source control?
  10. Do you create specification/requirements documents? Do you do it before, during, or after writing code?

Bad developer ≠ novice developer

My post on the nature of programming seems to have struck a nerve. Many commenters pondered what makes a developer great. “Ka” thought that:

“You [are] not born [a] good or great programmer, you become one with time and study and hard work. At the beginning, everybody is a bad programmer.”

I disagree. Developers are not born “great,” but greatness does not automatically come with experience. Conversely, lack of experience does not make a developer “bad.” The difference between a great developer and a bad developer is not in their domain knowledge, but their methodology. The distinguishing mark of a great developer is that he codes consciously. Put another way, a good developer always knows why he is doing something. From the perspective of personal ethics, this requires intellectual courage and integrity.

Let me give an illustration of what I mean from personal experience:

When I got into Objective-C development, I was a “bad” developer. Most of my experience is with .Net code. Jumping into the iPhone dev world was intimidating. As as a result, I lacked the courage to learn the architecture. I tried to manipulate blocks of code found on the web without understanding what they were doing. I would copy and paste blocks of code and just change variable names. When things didn’t work, I would look for another block of code to substitute for the failing one, or enter “debugging hell” – running code over and over, making random changes and seeing if they worked. This is the hallmark of a bad developer – imitating without understanding. I kept this up for over a year. It’s not that I didn’t try to learn the language. I got several books and watched iTunes U classes. But the way I used the learning materials was to memorize blocks of code and look for places to stuff them into my code. I wasn’t actually learning the platform, just collecting samples. Some developers spend their entire careers this way. They carry collections of old code everywhere they go, and just grab chunks to insert into new programs. They may never select File => New File or File => New Project in their whole career.

After writing a lot of bad, buggy code, I drifted back to the comfort of .Net. Recently however, I decided to change my attitude. I started by downloading some iPhone code samples and open-source applications. I started in main.m and went through each line of code. If I didn’t understand exactly why a certain symbol was used or what it did, I looked it up. I spent a lot of time on Cocoa Dev Central, Developer.Apple.com, and Stack Overflow looking up things like the reasons why you would assign, retain, or copy a property, or when exactly you need to release an object (for alloc, new, copy or retain) or what you can do with respondsToSelector. There’s really not that much complexity to programming languages – but if you don’t take the time to learn how things work, they will always seem difficult and mysterious. If I had just looked this stuff up to begin with, I would have been far more productive. But, I was intimidated by the environment and tried to shortcut the learning process by imitating without understanding.

Understanding anything complex requires the courage and integrity to engage in difficult, exhausting mental effort. It’s tempting to cheat yourself. It’s easier spend more time in endless copying and debugging that take the effort to understand and create. In the short run, it saves time. But in the long run, developers who understand their craft are magnitudes more productive than the monkey see-monkey do coders. This is the difference between the unprincipled kind of laziness that trades understanding for time and the principled kind of laziness which saves time by understanding.

There’s no happy ending to my story — yet. The proof of a developer is in his work, not his book smarts, and I have yet to produce something to brag about.

For more on the traits of great developers, read these posts by Dave Child and micahel.