5 Tips for Tech Entrepreneurs on Managing Software Development from Peter Bell

By John Critelli

Entrepreneur Peter Bell gave a presentation about managing software development for nontechnical startup founders during the Morris Tech Meetup at Fairleigh Dickinson University (Madison) on March 4.

Among his other accomplishments, Bell is an author, adjunct lecturer at Columbia Business School (New York), and cofounder of  CTO School, an organization that works to strengthen technologists’ leadership skills.

Here are five bits of advice from Bell’s presentation:

1. Know that the best software engineers won’t necessarily build what you ask for.                                                                                                     

 “Most engineers will make the horrible mistake of actually building what we ask them to,” Bell said. Instead, Bell added, the best engineers will work with you to figure out the real problem and develop the most elegant solution.

To demonstrate, he used the example of an e-commerce store owner who asks the developer to create an inventory list. “Three times a day, you’re going to have to remember to go look at that screen, scroll down, and see if you’re out of inventory for anything,” Bell said. “That actually wasn’t a particularly good thing to build.”

“What you really wanted was automated notifications” that alert you to low inventory levels, Bell said. And the engineer might have been able to build that even more quickly than the inventory list.

2. Use specific questions to identify a good software engineer.

Ask potential engineers to complete the Fizz Buzz Test— a programming challenge designed to eliminate weak developers, he suggested.

Second, he advised asking what meetups the engineer attends, to make sure that he or she is staying up-to-date on new developments in programming. Developers should spend at least some of their time attending meetups that have “something to do with programming,” and not just those that focus on the general tech industry, Bell said.

Third, ask potential employees a set of three simple questions:

•  “What ______ do you use?”

• “What did you compare it to?”

• “Why did you pick it?”

For example, a business owner might ask “What version control system do you use?” Next, the owner would ask what other version control systems the developer had compared it to. Finally, the owner would ask why the developer decided that  this choice was the best option.

Bell advised that business owners ask the same set of questions about unit testing tools and application frameworks like Ruby on Rails.

“This ends up being a really nice filter,” Bell explained. “Firstly, if somebody’s a professional software developer and doesn’t use those three things, they’re not a very good professional software developer.”

But if the engineer can answer these questions, “they’re probably a pretty good developer,” Bell said.

3. Create short units of functionality called “user stories.”

One of the best ways to specify a desired software feature is something called a “user story,” Bell said. “And, generally, they’re in a particular format.” The Connextra format is typically presented this way: “As a [stakeholder], I want [feature] so that [benefit].”

For example, a user story might be, “As the visitor to an e-commerce store, I want to see whether the store has any Wellington boots because I know I’ll need appropriate footwear to make it through the winter.”

Another user story might be, “As the manager of an e-commerce store, I want to be able to update our prices so we can stay profitable when expenses go up.”

A development team may create hundreds of user stories during a project. And any given user story should address a feature that can be programmed in two to five days at most. Bell said this is because developers usually provide the most accurate estimates when asked how long it will take to complete short units of work.

For each of these short units, the development team should use the “Three C’s.” These are:

• Card

•  Conversation

• Confirmation

 “Typically, you will put these user stories on a physical index card,” Bell said. However, the cards are usually just placeholders for conversations, he added.

 “Don’t bother writing detailed specs for every one of those stories,” Bell said.  Typically, about a third of the planned stories will be scrapped anyway. Instead, Bell recommended that employers have conversations with developers about a particular user story just before the work on that unit begins. These conversations will establish the specific type of work that needs to be done.

 Almost everybody forgets about confirmation, Bell said. “You’ve got to sit down with your developers before they write the code, and tell them how you’re going to test it.” Bell added that if the developers are competent, they will run similar tests and make sure the software works the way their employer desires.

 4. Sketches beat mockups for telling a developer how something is going to work.

 With detailed mockups, “you spend too much time making it look great and therefore stifling discussion with the team,” Bell said. “So, typically, when I’m working with a [development] team … I’ll scratch on a piece of paper. If necessary, I’ll show everyone through a camera” or use tools like Skitch, he explained.

 “I’m now getting the maximum value from my team, because they’re helping me to design things right, rather than just building the thing that I told them to because it looked so finished as a prototype,” he said.

 5. Have developers put their work in a repository (and pay them upfront for doing so).

 “If you took nothing else away from this [presentation], I would recommend that you get an account on GitHub,” (or a similar service, such as Bitbucket), and have your software developers save their work to the repository, Bell said.

 This guarantees that employers will have access to the code if their developers leave a project. And any new programmers working on the project “can see all the changes that were made over the last few months.”

 Developers may be uncomfortable putting their work in repositories without getting paid first, he said, but the tradeoff is “more than worth it.” Bell concluded, “Pay them weekly or biweekly in advance, so they’re comfortable that they’re going to get paid, and you have the code that you’re paying for.”