I was considering advanced origami last year, and I can relate greatly to the format for how we put projects together in computer science or any other engineering field for that matter.

First is the Planning Phase or the "study" phase. about 80 percent of a project is the time we take to study the paper we are about to fold and the model we are imitating or the blueprint we will put our architecture into place with. This requires careful scrutiny, testing, process development, and writing measurements out, all the while, throwing out a ton of paper. I use a lot of paper when designing software projects AND origami, but it is like I am folding this way and that trying to get the correct measurements to put together the animal or whatever is being modeled. In software engineering, there is a process called Test Driven Development, or TDD, where one must write out the stubs of methods and fail them until he engineer writes out the correct implementation to satisfy the requirements of inputs and outputs. Considering this, this also means that we must have a plan for what methods or functions we will have and what exactly their inputs and outputs will be. In a greenfield system, or a system we start from scratch, this requires careful procedures for illiciting the things the system will actually do, the functional requirements, and the bounds to which it will do things (like the bandwidth usage, the performance, the security constraints and concerns) or the non-functional requirements. Most of the time, an engineer will not be dealing with greenfield systems, but brownfield systems. They will be maintaining a system that is already in place and adding new features to it. This is something a new engineer must expect when getting into their career. Much of it may seem boring...refactoring, upgrades, patching...etc. But, this is what they signed up for. TDD would be applied with me features, and many other types of testing would be used besides the Unit Testing for making functions and methods to work correctly. Integration testing, Selenium testing, Functional testing, Exploratory testing are in that basket, just to name a few. Suffice it to say, this is ALL a part of the planning phase. We may even start with wireframes or prototypes, black boxes that really have none of the innerworkings of the final product. I have even heard of lean startups where the engineers will even use excel spreadsheets as a model for the future processes that the system will have implemented within. And, this is not even all the implementation. The framework will be blueprinted out, and all the method stubs will be created WAY before any actually coding or integration of other systems is done. TDD allows for development and implementation along with change. We all hear about this Agile Development model. Most teams at companies have different similar versions of this that suit their needs. I have never been in a job where they have used pure Agile, and it really is a buzzword for whatever managers want to do, much like "cloud" or "process management." Despite all these generic terms and the rigidity of a Waterfall Model of development (Requirements and Analysis, Design, Implementation, Testing), we must be understanding of the change that can happen to the system as we put it together.

Then comes the Rehearsal Phase. The planning phase and rehearsal phase bleed together. The study of the folds of paper and the folding over and over again to "get it right" can be both planning and rehearsal. However, this is the phase where we are prepping for production after we have the blueprint and start to build or fold. I have done some origami polyhedra, and this is an exceptionally important phase, where we count out all the pieces of paper involved, because sometimes a project will involve many pieces of paper, and fold them up to put them together in the shape. This would be where a team would purchase the third party services and software and, in reality, start to integrate all the pieces of software that have been written and do some integration testing. This is even more important in a brownfield system where we are trying to integrate newer parts into older parts. We want the engineered piece of artwork to be exposed in working order. This would be around 15 percent of the process of the project. And, this isn't even the most important part.

The last 5 percent of the process is the Presentation Phase where the whole thing is shown in all its glory to the public. This is when we would put our system in production. This is a measly 5 percent, and it may not even be the most important part. All that work the engineers, projects managers, QA, etc. did before led up to this penultimate moment. And, if the previous two phases were done correctly, then this should be the most successful. All things should be in working order, and all costs should be leveraged accordingly, money and time. From small teams to big teams, these are the things any project would require.

As I move forward in my career, I spend less time brute forcing a project to work, a conversation to be blabbered, a meal to be burnt, a origami animal or shape to be crushed out of frustration because the a paper would not fold any more or the thing just looks nothing like what it should, and more time focused on pondering my actions and words and painstakingly writing out agendas and plans with a pen way before I take action. As they say, "Haste makes Waste." Or as my favorite quote from John Wooden says: "If you don't have time to do it right the first time; how are you going to have time to do it a second?" My boss and his boss also say, "Measure twice, cut ONCE." Even ponder this as you plan your projects, but you don't have to take my word for it and hack away just to create something that would take less time in the long run if planned out accordingly or have a moose that looks like a rabbit or a snake that looks like a bookmark. Engineer wisely.