What is takes to deliver a software product?

Question

Hi,

Many of you must have been part of team which successfully launched products. What lessons you learned? Is there good literature out there which I can read? I was just reading this wonderful article, http://productmusings.wordpress.com/2006/11/05/20-rules-for-delivering-software-products/. And one point I really liked was "Make sure you only work on things that you need to ship with version 1.0." I realized, we are violating this point in our present project.

Answer 1

The article is exactly right: stay focused, and be really strict about what gets in the product. Absolutely do not give in to the temptation to build something "because we'll need it someday", or "it would be nice". Understand your future users, and keep them in mind at all times. Only build something if it will make them happier.

Answer 2

There is no single solution that works for all the software projects. Problems also differ from project to project. The main factors that can affect the solution and problems are the type of your software, the size of the project, the third parties that you are involved with, and the resources that you have for that project.

Answer 3

Depends on the type of product as I don't believe that the same advice fits all.

I can only really comment on large scale products that are deployed into enterprises ...

1. Fully research potential competitors e.g. technical solution, costs before you start
2. Identify the target release date of version 1.0 and stick to it BUT ...
3. Record and maintain a roadmap of the features that cannot be fitted in the first release
4. Consider the authentication and authorisation model carefully and ensure it is flexible to be configured by customer (No organisation is the same!)
5. Make sure any interfaces are designed for interoperability
6. Ensure that there are clearly defined extension points for the delivered functionality
7. If relevant to the target domain ensure the product is scalable from the beginning
8. Resist changes to your architecture for your first customer (or any for that matter)!
9. Ensure that your deployment and upgrade strategy is well thought out
10. Make sure that core users scenarios (always about 5 key scenarios) are the smoothest from a usability perspective
11. Make sure than and 3rd party components that are used are robust and encasulated (e.g. go for Enterprise Library over a bunch on open source)
12. Establish your development standards early (e.g. FxCop or unit test from the beginning)

I could probably list another 20 or so!

Answer 4

• Avoid "scope creep": Focus on here and now.
• Do some "hallway tests" with guys who are not from development.
• Communicate: Talk to Your customer, if You run late. Maybe he/she wants to drop a feature for an earlier release date.

Answer 5

Wow - good question! I think the answer depends much on the scope and breadth of your software. For example, I own two shipping things at Microsoft (in Windows). One is the xperf suite of performance tools and the second is the WinSAT tool and WinEI. I also have a couple of pet personal projects like a string finding (grep) utility. All of these have very different requirements to "ship".

For Windows features, we have a lot of things we have to do before we can ship. Of course, we do a lot of testing. Code reviews and other things most developers do are common. But some things stand out as especially important due to the nature of Windows.

1. Security, we spend a lot of time on this collectively. More for some components, than others. Larry Osterman's posts on threat models will give you an idea of the work we do here.
2. Internationalization. All windows components (with very few exceptions) must be support full internationalization into many languages. We have a very large group that focuses only on support for this.
3. Accessibility is essential. While the fundamental UX infrastructure does most of the work, we do spend a considerable amount of design, implementation and testing time ensuring that our UI works in high contrast mode, with big fonts, with narrators (screen readers), has workable keyboard access, and otherwise works well for disabled people.
4. Of course we do a lot of testing, but one of our key tools is Windows Application Verifier. This tool is just golden. It will find all kinds of errors in your code that are expensive to find with regular testing. If you are not using app verifier, you should consider making it part of your testing program.
5. Reliability is key. We look at our crash data regulatory and triage and fix any problems people see. Note - always choose to send data to Microsoft when Windows or another Microsoft component asks. There is no personal identifiable information in the data sent. Most important, this data goes straight to the team that owns the component. Our feedback systems automatically file bugs assigned to the owning team based on this data.
6. Servicing is super-important for us. We test and otherwise make sure we can issue QFEs, HotFixes and Service packs without breaking things. This means making sure our manifests are correct, understanding all the binary dependencies we have, and planning things so we don't break application compatibility.
7. Telemetry is important - we need to know when our components fail (other than crashes) and how they are used, and how often. Our components are heavily instrumented with SQM. We really appreciate people that opt into any Microsoft ccustomer experience improvement program. We don't know who you are (no PII data is collected). But the data is really, really helpful to us.
8. Full 32bit and 64bit parity. Almost all (I don't know of any significant exceptions) windows components are built for x86, AMD64, and Itantium. All components included in server SKUs must work correctly on all three environments. Client features must work correctly on x86 and AMD64. Its not fair to say this doubles the work, but we do make sure all flavors build before we check code in, and we do test both thoroughly. Many people self-host (dogfood) on 64-bit (I do).
9. Mobile, Mobile, Mobile: Battery life and power efficiency are key for mobile systems, and also for desktops. Components need to be power-smart. This means lots of things:
   • being smart about idle, polling is bad
   • not spending up the system timer tick unless absolutely necessary.
   • where appropriate, being AC/Battery aware and scaling back when on batteries.
   • where appropriate, being power policy aware, behaving differently based on what the user has selected.
   • being smart about the user of timers (these cause code to run and thus energy to be used).
10. Deployment and licensing. Our xperf tools ship "out of band" (e.g. they are part of Windows, but not "in the box" or "on the disk". So, we need to build an installer, make sure we have the right license agreement. Etc. etc. This is pretty common to lots of software.
11. Developer Documentation - we spend a lot of time on this for APIs and our xperf tools. This is an area where we literally cannot do enough work. The dev team spends material time feeding info our tech writer. (I wish we had more than one).
12. End User docs - for us this is Windows Help content. We work with the help writing team. They do all the hard work of editing, and translating the help into all the languages supported by Windows: its not only UI strings that get translated :)
13. I think its fair to say that Microsoft is beginning to get good at supporting and communicating with what we call the "eco system" and many people would call the community. I also think it is fair to say that we are bit late to the party. Now, in Windows, this is pretty ad-hoc and up to teams. For example, I blog a bit about the xperf tools and other perf stuff. We just setup a forum for the xperf tools. I think this is an important part of delivering a software product.

Now, I'm not suggesting that every project, or your project, need to deal with all these things to the degree (or as some might say, -not- to the degree) that Windows does. But I think that all of these things are important to most software products to one degree or another. For example, have you considered how you get telemetry from your users?

Best Regards, Foredecker

Answer 6

Many have noted that small programming teams often do best. If the project requires an army of programmers, they should be divided into small teams and directed towards distinct goals, which means you now need an architect to make sure the separate pieces fit nicely.

Beyond programming, someone also needs to represent the customer (product manager) and someone needs to take care of all the other details (program manager).

Everyone involved in really big projects should read Brooks' 1975 classic "The Mythical Man-Month" because these sorts of expensive mistakes are still made today, and we should all know better.