I came across a post that raised a few very good questions about the software business, so I thought I would respond.

• How partial can the initial result be and still matter?
• Partial in features or partial in quality?
• Is a later corrective delivery a separate, on-time delivery, or a completion of the initial delivery, thereby making it late?

The underlying question here is how do you make the decision when you can’t deliver on scope, quality, and timeline, how do you choose what to sacrifice? The original author makes a good analogy:

If you’re running for a plane and lose a shoe. Better to make the plane and buy new shoes at the other end, right?

And of course, the counter point:

What happens when the client you were going to visit by plane is on the plane, sitting next to you?

To be consistent with the focus of this blog, I think there are a few rules that apply here to software development teams:

1. Know your users. What will your users accept? If this is a critical, life or death piece of software, quality probably can’t suffer but timelines are allowed to move. If it is an business process automation application, then maybe quality can slip since the ship date is critical.
2. Use your Product Manager. I made a previous post about the value of product management (link), and this is another benefit. Usually, product management owns the customer base and profit / loss accountability. (In your organization, this could be sales, marketing, or a business unit GM. In those cases, target them with this advice). At the end of the day, your team is not held accountable for P & L. Your team is responsible for fulfilling requirements provided by product management. You are not directly tied to the customer or the sales cycle (yes, I know this is slightly different in small companies, but realize that the roles are there, you are just wearing different hats). Let the product manager determine which aspect of the project to sacrifice.
3. Use your best judgment. In the event that you are left to make the decision, go with your experience. If you were the user, what would you prefer? Could you postpone a feature? Could you delay part of the product? Someone has to make a choice, you just need to accept that no choice is going to be popular. Everyone will want all features with all quality on time. Your job is to get past the emotion, and recognize that it just isn’t going to happen this time, so it’s time to make a mature, rational decision about how to proceed. The inevitable “how did we get here” question will certainly come up, so you need to be prepared for it. Remember, history is a great instructor for the future, but it can’t be changed regardless of how much you talk about it.

These are decisions that come across my desk all the time. As a general rule, I try to stick to rules #1 and 2, but in the event I need to decide, I do so. Trust me on this one, indecision is far more costly than the wrong decision. I’ve made a bunch of decisions about projects and scope. Some were right, some were wrong, and some were very, very wrong. Bad decisions happen, the trick is to manage past them, not to let them define you.

The full post can be found here: Link.

Technorati : Development Management, Management, Product Management, Program Management, Software Development Lifecycle, Software Management

I realize this is all over the web, but I’m just getting it now. Robert Scoble, one of Technorati’s top 100 (#26 as of this morning) bloggers, is leaving Microsoft for startup PodTech.Net, Here are a collection of links that are a valuable read.

• Scoble’s take – Link
• Niall Kennedy’s Homage
• Chris Pirillo – Link
• Silicon Valley Watcher Article- Link

I’ve been reading Scoble for over a year now, and I must say that he is truly a blogging superstar. He is the first blogger that I can think of who did a great job of balancing his insider access as working for a major software company with his general geekdom passion by writing very openly about anything in the world of technology. While no one in the blogosphere will miss out with his continued postings, and Microsoft will continue to have over 3,000 other bloggers, they have certainly lost their heavy hitter in the blogging community. Good luck Robert!

According to Rob Hof from Business Week, Digg’s CEO announced today that his team is hard at work to expand Digg beyond tech news and sites, and expand into news, politics, and all other worldly events. Read the full posting here.

Technorati : Digg, Reading, Software

Joel Spolsky is an incredibly interesting author. He’s written a few books, posts regularly on his blog, and at the same time runs a successful software company. You can search through his blog and see some of his other postings on software management and development, his process and theories behind hiring summer interns, but I recently came across what I think is his best idea yet: The FogCreek MBA program. His premise is that to be ready to run a software company, an MBA doesn’t do you any justice, but he is planning a three year crash course for recent graduates that at the end should prepare them for anything the world of software has to throw at them.

You can read all about the FogCreek MBA program it here. Joel also posted a recommended reading list for this program that can be found here.

Technorati : Development Management, Joel Spolsky, Management, Reading, Recruiting, Software, Software Development, Software Management

I may be in the software industry, but this is a problem that affects every manager in every field. How do you recruit and hire the best talent? There are the general cliche's like "Hire people smarter than you" or "Hire someone you could work for," but these don't actually give any information you could use.

Everyone has their own process for hiring and I've been through several as both a candidate and an employer. The best tip that I can offer for how to run an interview is that the candidate should meet with several people, and all on the same day. This makes it a one-stop shop for the candidate, and allows the company to react quickly if they decide to move ahead with an offer. I'll make a future post on my idea of a recruiting / interview process.

Anyone who's ever given an interview should know that they are walking into the interview preparing to answer one question when they're finished: "Should the company hire this candidate?" The question sounds fairly easy to answer, but the process to get there is complex, and sometimes requires a crash course in psychology 101. I've compiled some tips below that I try to follow with each interview I give.

First, let me put my interviewing frequency in context. I am one of the key interviewers for my company, usually giving 5 – 10 interviews / week, ranging in candidates like test engineers, software engineers, software architects, project managers, program managers, and product managers. While a typical interview with me lasts for 45 minutes, I probably have 2 – 3 hours worth of interview material.

The biggest struggle that I see, especially in first time managers, is the ability to recognize talent. Senior people are always easy to hire; they know their area of expertise, they pass all of the technical interviews, they have the experience of several software projects, and they are mature enough to give the expected answers during the interview. For them, it just comes down to personality fit and they either mesh with your team or they don't.

It's the diamond in the rough that seems to be the most difficult to identify. And these people are the most critical to your project; the 'B' players; the group who makes up 70 – 80% of your team; the group who'd you love to see a few grow into 'A' players. So how do you sort out the candidates with potential from the ones who are just repeating what they memorized in the latest programming book they read. The basic knowledge is usually the same. The candidates most all be competent in your technology of choice, they must get along with your team, and they must fit your budget range. Now the hard part, once you've identified a few candidates that fit these basic criteria, how do you know who will really succeed? Who will improve your team? Who will exceed your expectations?

1. Evaluate Problem Solving. Try and find out how the candidate works through a problem that they don't know the answer. How do you weigh a 747? Why are manhole covers round? How many cars are there in New York City? Questions like this are not designed to reach the answer, but to see how the candidate thinks. How do they respond to help? Do they ask questions? Do they break down the question logically or randomly? These are some key indicators for imaging the candidate 6 months down the road when you have to develop a solution that no one on the team has ever seen before. Maybe an obscure defect that you can't reproduce These situations will inevitably come up, and you want your team best prepared to handle the unknown, and be able to breakdown a problem logically.
2. Hire Smart People. When in doubt, hire based on intelligence. Generally speaking, intelligence has a direct correlation to ability, adaptability, and efficiency. I'm not saying this is a black and white issue, but when you can't decide between a few candidates, the smarter candidates have a higher probability of success
3. Admitting Ignorance. Throw out some questions that the candidate has no way to answer. Don't throw out a brain teaser for this one, but throw out something extremely technical or deep, or on a technology just outside of their knowledge level. You already know that they don't know the answer, the test is whether they'll admit it, try to dance around it, or engage you in a conversation to get to the answer. As a rule, anyone who tries to give me a b.s. answer, I immediately won't hire. Anyone who can admit they don't know something when they are engaged in an interview is someone with the maturity you are looking for. Professional maturity is a great indicator for future success, knowledge transfer, and constant growth.
4. Communication Counts. Try to get the candidate to explain something complex to you. Did you understand it? Was the information presently structurally or randomly? How long did he consider his answer? Was he comfortable launching into a diatribe? At the end of the day, communication is key for any team, and yours is not any different. As long as someone can clearly express their status, position, opinion, thoughts, really anything, then your chances for team success have just gone up exponentially.
5. Career Goals are Good. Senior talent generally know what they are looking for, and have usually already achieved some career goals. Entry level people probably have no idea what they're looking for, but just have some skills out of school and are looking to learn. Again, it's the middle group who really have something to prove. You want to make sure that your candidate has some goals, and he's on the path to reach them. The actual goals aren't very important, it is that there is a career plan being executed. It shows forethought, direction, and purpose. The one exception to this rule is if the candidate's career goals don't map to your field. For example, if someone came in and told me their ultimate goal was to save up some money and move to Outer Mongolia, and they are 4 months away, I probably wouldn't hire them. Outside of that, you're in good shape.

I'm sure that there are other beneficial characteristics to look for, but these are a few that I use. Anyone who'd like to post more tips, please comment this post. And remember, interviews can never determine if someone will be a successful candidate or not. Interviews can only increase your probability of selecting a good candidate, and all you are trying to do as the hiring manager is to hire the candidate with the highest likelihood of succeeding.

Here are some other links around the web that I've found as good reading.

• Guy posted a reader's email – Link
• About.com article – Link

This will be a future post, but here are some postings about how to retain talent once you hire them.

• Why Developers Leave – Link
• Harvard Business School on Lost Motivation – Link

Technorati : Development Management, Management, Program Management, Recruiting, Software Development, Software Management

I thought it might be nice to post a list of the initial topics I plan to post on. I'll update this post with links as I post the content

In no particular order

• The Value of Product Management
• How to Negotiate Scope
• SDLC in the Real World
• How to Hire Talent
• How to Grow your Employees
• The Value of Automated Testing
• Strategies of Software Teams: New Development vs. Maintenance Development
• Strategies of Software Teams: How to transition to a New Technology Platform
• Does anyone really want to be a CTO?

I'm open to any input for other topic suggestions. Like I said aboe, I'll be posting in a fairly random order, but I'll be trying to post at least one topic a week.

I have no idea whether anyone is actually reading this blog or not. I followed all the steps I could find, registering on technorati, bloglines, feedburner, etc… If you actually are reading this blog, just leave me a quick comment. Any feedback on what you’d like me to write about would be fine too. I’m just wondering if anybody “hears” me.

Breaking news, I'm sure there will be plenty more coverage by mid-morning.

 Full Story

Well, the research is Microsoft hosted and funded, so of course it is somewhat biased, but it is not a rediculous endorsement of Windows Mobile.What I'm really hoping for is that the Motorola Q (Link) will help bring Windows Mobile to the general mindset as a real competitor to Blackberry.

Personally, I've used three different smartphone platforms, Blackberry, Windows Mobile, and Symbian (Nokia, Sony Ericsson), and my personal preference is the Windows Mobile platform. The reasons for me are fairly straightfoward: Multi-tasking, familiar Windows interface, easy synchronization with Microsoft Exchange, 0 incremental cost for my IT organization to support real time device mail push, and the ability to develop my own applications. Yes, I know I could develop for Symbian or Blackberry, but I am skilled and comfortable with the Microsoft dev platform, and it is virtually no effort to write for the WM platform.

Summary

White Paper

This post has been moved to my new blog address: Link

Technorati : Cell Phones, Dopod S300, HTC StarTrek, HTC StarTrk, Smartphone, WM5, Windows Mobile

SDLC – System Development Life Cycle (SDLC) – a methodology used to develop, maintain, and replace information systems.

I’ve run into more than a few project managers, developers, testers, and product managers that have caught the SDLC buzz word fever. They’ve either latched onto the newest, latest, coolest, hippest methodology, or they read in a book that you can’t succeed without one, or (most likely) their manager said that they need to have one. However they get to this state of mind, they usually follow the same course of action.

1. Go to bookstore and buy 1 book
2. Read at least the first few chapters of said book. Some even make it all the way through
3. Go to their next team meeting, and declare that they are implementing an SDLC. No one else can ask questions or offer input, because the book says it will work exactly as its written
4. Meetings are called with subjects that mysteriously match the book’s chapter headings
5. The rest of the team has no idea what is going on, but they are following their enlightened SDLC leader blindly. It still seems like they’re writing and testing code, so at a granular level, most everything seems to be the same
   …… The Project Continues …..
6. Utter chaos ensues, the product is late, the quality suffers, and it is deemed that SDLC’s are worthless
7. Team reverts to prior process, and ships with previous efficiency, tracking, quality issues, and date slips. While that may sound bad, they still ship and shipping software is a key test of success or failure in commercial software.

So where does the value from using a methodology come from? For me, it all comes down to one thing: change management. If there was only one programmer, and he knew the customers, wrote the requirements, wrote the code, tested the code, fixed the code so it was bug free, packaged the product, and shipped it, there would be no need for an SDLC. OK, now back to the real world. Requirements change. Team members quit. Testers miss bugs. Developers write more bugs when they fix the bugs QA already found. Customers can’t articulate what they want. The list goes on and on. This is where having a defined methodology helps. It gets your entire team on one page. When someone falters, everyone knows, and everyone understands the impact of what that means and can adapt. It is not a blame issue, but one of good communication. When you have a team driving toward a common goal, working in a common way, helping each other succeed, then you have a team with a shared vision. A team with a shared vision can do amazing things. They can have requirements change at the last minute, and everyone knows where to help, who is impacted, and how to react. The same scenario goes into effect when someone on your team leaves. Normally, the team is lost for a bit. Some piece of critical information or a critical process lived only in that person’s head, and now that they are gone, the team is lost. Again, common steps, common process, common knowledge, shared vision, and teamwork. All of this leads a team to be adaptable to change, and having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software.

Having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software

Then how does all of this apply to me? I’ve been through a handful of projects, and I’ve learned the most important lesson about SDLC: No SDLC is perfect. All of those books look really good in print, but they are all based on best case scenarios and case studies. The key is to learn as much as possible, study many methodologies, and adapt a methodology to your team. I have a personal methodology that I usually try to follow, with parts taken from a few different communities, but with each new team and each new project, the process is adapted. The value of a process is to help organize your team, not to organize your team according to the process. There is always pain, resistance, and adaptation when implementing change, but it should be for the betterment of the team, not because you are trying to fit the team to something from a book.

This is the general methodology that I have used successfully in the past. It is a combination of a traditional waterfall development cycle, but focuses on short term, iterative deliverables during the development cycle. These are similar in principal to sprints from the SCRUM methodology (my personal term is protocycles), but with a different up front planning process. There are also aspects of XP and MSF woven throughout, but I won’t get into that many details in this post.

1. Establish high level requirements. These need to be detailed enough that the technical design can be built from these requirements. This deliverable essentially drives the vision for the release. A 3 release roadmap is also required, so that the development team can understand what the future product plans are, with as much clarity as possible.
2. Define the detailed requirements. This task takes the high level release requirements, and drills down to a sufficient level of detail required for the development team. As each detailed requirement document is completed, it is sent for peer review and acceptance by a representative from development, quality assurance, architecture, product management, and development management. This task happens in parallel with the technical design.
3. Define the technical design (Architecture). Based on the high level requirements, establish a product architecture taking all three releases requirements into account. The architecture deliverables for version 1 should be at sufficient detail for the development team to use, and mock architectures should be vetted in order to validate feasibility for the version 2 and version 3 requirements. This task happens in parallel with defining the detailed requirements.
4. Product Development. The development team executes the detailed requirements and the technical architecture. This process is somewhat agile in nature, since features can be started once the specification for that component is complete, rather than waiting on an entire requirements package.
5. Quality Assurance. The QA team validates the software created by the development team meets the defined requirements. Test cases are created for each completed requirements document, following its peer review acceptance. For a test engineer, the requirements should read like a contract, validating that development met their end of the contract. As is typical during a development cycle, requirements will change. These will be handled as requirements addendums or modifications.
6. Release to Manufacturing. This is the final step in the process. Once a product is ready to be delivered to market, this step represents the processes preparing for general availability. Depending on the organization, this could include source code escrow, marketing coordination, gold CD creation, retail packaging, etc… The timing for this process is generally organizationally dependent.

There it is, how to ship software in 250 words or less. I’m not trying to demean what any of us do, but at the end of the day, it all sounds so simple, doesn’t it? Define what you want, research it, document it, code it, test it, give it to people who will pay you for it.

Technorati : Development Management, Management, Methodology, Program Management, SDLC, Software, Software Development, Software Development Lifecycle, Software Management

I've read Jack and Freakonomics. Not a bad list. I'll add to this in the near future with my pics.

Read

There's plenty of press about this one, but I thought Scoble had a good quote:

I want better software. Competition brings better software. It gets product managers to worry about customers. It causes discussions of features that were long-ago decided on.

If you want to see the other articles, click here.

I try to spend a few hours a week reading articles on the web. To me, the word "article" has a loose definition, but basically anything someone has taken time to put together that adds knowledge or value, I'll read if I can stumble across it. Here are this week's selections:

• All Code Has Bugs – Link – Full Article
• Google Hiring Strategy – Link
• CEO Reading List – Link
• Art of Recruiting – Part 1, Part 2

My background is in software development and architecture, so here are some good blogs that I try to read regularly.

• Martin Fowler – Enterprise Architecture
• Don Box – Windows Communication Framework Product Team
• Architect Linkblogs
• Tim Berners-Lee – Father of World Wide Web