Quality Is a Pet-Peeve
When startup companies start development, they very rarely consider making a detailed design of any kind, or even a simple roadmap that shows their goals. The goals seem to all be based upon getting something to work, something to show, and something that will get funding. When done, then they need a whole bunch of money to get their piece of crap into a usable state instead of just a demo platform. That is point number one:
1. Make a design
-- Every building has a blue-print, or a really nice CAD drawing that describes its every detail. Don't get caught by the Sirens (Greek mythology) calling you to drive your ship to the rocks with their sexy voices that tell to short-cut thinking and start coding. Make a plan. If you are a Scrum shop, or doing any kind of agile development, make sure you join this stream of consciousness style of development with a pure, tested, well weathered game plan. Scrum, XP, and all forms of project management include pre-game planning for every stage. Your pre-game should include as much analysis time that you can possibly put in to make your basic design solid.
2. Have written requirements.
-- This sounds basic and obvious. It is not. I said this out of order because requirements come first, right? Usually not in the web world. We get our ideas, see the appeal or empty space in the market, and go into designing what we see as the basic need. That's ok, even to the purest software engineer at heart that I am... as long as it's combined with a serious amount of work put into documenting your system's requirements. Requirements are not all made equal, and I could run on forever on that topic. I won't, not this time. The key: make your requirements part of a continual review effort that include comparing requirements to design, and a review what has been coded, against requirements, and then design... it's cyclical. Whenever a bit of code doesn't work, you will probably find a requirement that is poorly written, not written, or was misunderstood by one or more developers.
3. Projects go in one direction -- forward.
-- Free - thinking direction exists in agile development methodologies, and variants in the well-used term "waterfall" or traiditional PMBOK style project management techniques. That's a good thing. Remember that projects, just like people, live only in one plane, the present. We plan for the future, work in the present, learn from the past, and recall the glory days with our buddies when we are successful in hitting our targets in business. keep the ball moving forward. If there is a technical challenge that is not surmountable due to budget, that's actually great. You've cleared the hurdle by identifying it. Awesome. Now, put it into your "bucket list", and move onto the other items that are not dependent to keep things moving forward. If the entire project is dependent upon this critical piece, then you have probably failed earlier when you neglected to make a design based upon clearly written requirements. Design is where the hard thinking should come. Coding is more tactical.
4. Have code reviews
-- Code reviews are an excellent opportunity to review work against two incredibly important measures: code quality standards, and requirements.
-- Make code quality standards that make sense for your company, project, assignment, and/or team. Ask the best brains you have to come up with coding standards. Then, go online, and supplement these standards with some from any you find out there that make sense for you. In the end, standards are very personal to your situation. The exactitude of the standards are not worth arguing about for very long. Most important: your enforcement of the standards. Just having a standard, with reviews, with periodic audits of those standards, and their use across development -- this does wonders for the attention to detail that projects receive from their contributors. You could almost say, "make the code look like shit", and your development work improve because people were actually agreeing on an overall approach :). I've seen examples that almost match that maxxim... you'd be surprised.
5. Don't worry: the big companies don't do it better, they just have more money
-- In my more than 20 years professionally working after college, and in the years before when I was programming for fun at 14, I've only seen 3 examples of projects that followed excellent development methodologies. What I give to you in this blog is the culmination of that experience.
6. Every project will take much longer than you think
-- When I was at Intel, I was voluntarily in charge of coming up with the overall plan, and budget forecast for the largest database ETL project ever done at Intel at that time. There was no school-based training for forecasting. You used your experience, your intelligence, and more than 50% -- your gut. I was asked to deliver a forecast for hardware utilization, and cost for a 5 year continuous improvement model. That basically meant that my career at Intel hung on my ability to figure out what something that had never been done would cost, and need for hardware memory and storage for 5 years into the future -- without any guidance.
-- Faced with a goal that is driving toward the unknown, you look for what is known AROUND then problem that helps to describe it. Michael Angelo once described his stone carving process by saying he looked at the piece of marble and removed everything that didn't look like the thing he wanted to make. He started that way because even with stone, you don't know what you have until you start cutting Lots of rocks split in half during carving because they have deep cracks that you can't see. (My Dad is a sculptor... ). Software is no different. Measure what you know. When I didn't know how big the database would become, I quickly realized in asking questions that no one knew... it wasn't my failing. So, I asked other questions. Intel is a chip manufacturer. What was our database to store? "Chip data from several series of new chips and processes".
+ That's one set of data to get -- new chip design changes and new processes supporting
Will data be stored from all of the older chip platforms as well? (In this case, from testing the chips in the factory). "Yes. But, we are EOLing the older chips on separate schedules, over maybe 5 to 8 years, trailing down factory to factory as they convert to the newest chips and processes. Some factories will be shut down too but we don't know which ones yet"
+ OK. Add existing data stored in the existing database that I helped to write 5 years ago. Easy to get that, just ask the DBA
We are converting from DEC hardware and programs to HP Intel-based systems, in C++ and Oracle, right? "yes"
~ Factor in possible delta storage requirements for redundancy, reliability, failover, and reporting. Existing system has reporting off of the same database as that being loaded. New systems will need to be separate to properly load balance.
There was a lot more... but I took these factors, and made a pretty complicated spreadsheet that extrapolated from the new transistor count of the newest chips being produced, and demonstrated a ratio between past chips and present. This ratio was applied to represent delta (new) data needed on top of the existing data. So I was able to double the size of all existing databases, and multiply my ratio against them, add it to the total, and then I had an abstract measure for total storage space needed -- but that was just for the exact data to data comparison...
Like I said, it was complicated, but it just took an investigative mind to get through to an end result that was very well received... but very expensive.
7. Stuff always costs more than you want it to... Embrace the cost, buy more than you need.
-- Once you really think you have a good plan, don't shortcut reliability in any area that aligns with your critical path. Pay for more than enough hardware, cloud-space, or excess capacity, up to and including 50% more. Save money in WHAT you are developing, not in where it is being hosted, or what hardware or software is driving your performance or reliability. You can hold off on development of a new widget or an item on your schedule, but you can't undo a bad hardware or hosting choice very easily.
8. Test the crap out of it.
-- Muy importante: test at every interval. Unit test continually. Test before code reviews. Create regression test plans. Test case development is an entire set of blog entries. I'll save this topic for later. More to come...
Summary:
1. Make a design
2. Have written requirements
3. Projects go in one direction -- forward
4. Have code reviews
5. Don't worry: the big companies don't do it better, they just have more money
6. Every project will take you longer than you think
7. Stuff always costs more than you want it to... Embrace the cost, buy more than you need.
No comments:
Post a Comment