Peg Bogema, vice president of operations at Ann Arbor-based Stout Systems, spoke with DBusiness Daily News about providing software development and staffing services to non-traditional technology companies.
1. DDN: What observations have you made from working with companies that don’t specialize in software development?
PB: Many of the companies that we’ve worked with fall into that category, where they’re automating one of their processes or offering a certain service (or web application) in order to keep up with their competitors. They don’t view themselves as a technology company. Under those circumstances, there’s often somebody who's running that activity who is an accidental or reluctant software development manager. They’re not trained software development managers by trade. They might not even have a background in computer science. They get the role thrust upon them perhaps because they're smart, or they’re willing, or they’re in the wrong place at the wrong time. And when we walk into these types of circumstances, we face a whole different set of issues.
2. DDN: What kind of issues?
PB: The types of best practices that we would normally expect to walk into, we're not walking into them at all. So we find ourselves educating this person about best practices.
3. DDN: What are some examples can you provide?
PB: One is maintaining proper source control, so your source code has to be maintained in what’s called a source repository or a source code repository. Many companies don’t do this. Their code is sitting on one software developer’s computer. If that computer goes down, they’re in deep trouble. We also run into situations where the company doesn’t know how to determine what they should build next, because they’re not tracking user complaints, the types of bugs that are being found, or the enhancement requests that are being made. And yet, those requests and complaints are the most fruitful source of information. If you don’t track those things, what you’re going to release next is kind of whimsical. It's based on one person's opinion, or, God help us, the developer’s opinion. There’s often poor mistakes made in that regard.
4. DDN: What decisions should the developer be making regarding the content of the project?
PB: (They should be establishing) the scope of the release. This is something that is often overlooked in an unstructured development process, where they don’t formally (identify) the boundaries of what’s going to be included in the next feature release. So then there's somebody who's saying, “Well, what about this? And let’s add that, and this is really important, too.” A good software development manager knows how to structure what’s going to go into release and actually get the release out the door before moving on to the next set of functionality.
5. DDN: How does this impact the development process?
PB: If you don’t have somebody who can make the trains run on time — someone that says, “This is the content of our next release, this is what’s going to get done in that release, and this is how we’re going to test it and get it deployed.” You’re basically wasting your time. This release date can slip and move and the content can change, or people may change their mind about what it is they want. And you end up never releasing, or what you do release takes so long to get to the market that you’ve kind of missed the boat.
