All businesses, like Polytron, have strategies that they use to manage and promote their projects. Many names are given to software development strategies – Agile, Spiral, Waterfall, to name a few. Wikipedia lists over 70 of them. At a simple level, they can be categorized into two opposing methodologies.
At one end of the spectrum is what I call the “Document First” method. Document First methodology dictates that everything be 100% designed, documented and approved before any programming starts. The thinking here is that it is easier, quicker and cheaper to change documentation than it is to change program code. Therefore, it is more efficient to document what you are going to do before starting to write code.
At the other end is the “Program First” strategy, which says, “Let’s just start developing code.” In an iterative process, functionality is added over time along with incremental testing. The solution may be documented at the end of the project if time and money are left over. The thinking here is, “Why spend time trying to document a design before determining the programming specifics?”
Usually neither one of these two strategy extremes works for Manufacturing Intelligence (MI) projects. A one-size-fits-all approach does not suit MI software development; individual software modules of an MI solution normally require unique strategies. Documentation may be less critical when no new, unknown or untested technologies are involved in a project, but an MI project that is nearly a clone of a previous project is rare.
- The Program First methodology may be appropriate in situations where a small piece of the software project is new and untested. Prototyping can be used to develop and test small sections of the code before committing to a design and moving forward.
- Document First is usually implemented for large, complex projects where a team of software developers works on the project. Documentation is the blueprint to communicate the overall design and make sure every member of the team understands how the components interact with each other. It is also instrumental in preventing scope creep and change orders during the life of the project.