ABCs of product development
These should be obvious to anyone who has developed a real software product before. But, recently I had talked to a few people who were working on their first large scale projects on their own but were making some basic mistakes without realizing it.
1. If you are developing a new product or technology, prototyping and research is a must. Agile development methodologies are good, but for a large scale product use agile methodologies after your research phase.
2. Prototyping and research often takes longer than developing the actual product itself. Someone should actually write a prototype which acts as the prototype for modularization & abstraction as well if possible.
3. Always separate your UI code from your non-UI code. Often, the non UI code will be implemented as services in the windows platform. Develop a fool proof mechanism to keep the software upto-date as well.
4. Never try to automate your UI testing first. It should be done only after automating tests for the non-UI portion. The tests should be such that they perform the test and are able to validate the success or failure as well. Every bug which is found should be part of your automated test suite.
5. Plan to have daily builds if your team is more than 5 people and run your automated test suite on every build. If the build or the tests fail, make it the first priority to fix it.
6. Setup is not an after thought. Plan for upgrades, patches, partial upgrades etc before your first release. Use VMWare or similar tool with snapshots for setup testing to save time.
7. Use the best tools for the job. Pick the language, IDE & server technologies which are the best fit for the customer - not for you. ie. Don't develop in C because you don't like C#.
8. Use peer reviews for improving code quality. Every checkin should be reviewed by lead or peers before it is committed. It is all about catching bugs early on in the development cycle.
9. Architecture & good design are a must if you expect your product to be in the market for a long time. Think about changes in market and the possible different uses your components could be put to. Learn this elsewhere, not from this blog.
10. Security in today's world is important. Your reputation depends on it. Think about it when you design, not when someone finds the first vulnerability in your product and your reputation is already lost.
11. Three documents which should be ready before development starts are Functional Specification(is done when design& test plan can proceed), Design Specification(is done when coding can start) & QA Test plan(is done when testing can start). Preferably, do a team review of all of them
12. Remember that products never get filled with hacks in one day, it takes small hacks everyday to create a monster which everyone wants to re-write because they do not understand!
Comments
Some tips that I would like to add.
1) Set benchmarks for your product before you start coding. In fact benchmarks should be part of requirements.
2) Don't think about coding till you are design complete.
3) My ex boss, Dave Donovan, used to say C++, COM, Windows, everything can be learnt by reading a book.
A good engineer is the one who know how to design well.
4) For COM developers, learn that COM does not guarantee OOP. So many times I see developers rushing to create new components. Creating COM components must be debated. Can it be replaced by a class, can the class be replaced by a method or structure. Remember a class should have characteristics and behavior.
More than once in my career I have seen people reducing COM components to improve performance.
5) Pair programming has proven to be a wonderful concept.
6) Learn to say no (especially people coming from a "Yes Master" culture). It is better to launch a product late rather than to dump a craptastic product on the market.
7) Have a life. If you are always working on weekends and late night it means one of the following things.
(a) You are technically incompetent.
(b) You don't know to delegate.
(c) You don't want to delegate because of your insecurity.
This attitude of wanting to do everything by yourself will hurt you the most in the long run.
(a) You will be too engrossed in your work to notice the world changing around.
(b) You will develop a myopic, tunnel vision.
(c) You will develop an attitude, "my way or the high way"
8) Respect and trust your junior team mates especially the ones right out of school. Their raw, unbridled enthusiasm can launch great ideas.
I have seen the best engineers saying "can't be done" only to be proven wrong by a fresh graduate who didn't know it "can't be done"
9) Don't pinch pennies when it comes to buying tools. Some tools I love Perforce, Bounds checker, Purify, Win runner.
10) Change teams on a regular basis. Working with different people with an open mind is the best way to learn. People who have worked in more companies benefit from the different cultures, functionalities, technologies….