If they’re not, they should be.
Once too many times I’ve seen development go awry. It’s insane to think that you can build a full application by code alone. Since the days of “modern” programming practices, such as OOP and frameworks, there has been this misconception of the code documenting itself. What a misnomer!
Proper software development is done in three main stages. 33% of the time should be spent on documentation. 33% on development, and the last 33% on QA. The leftover 1% can be spent on whatever else you’d like. But seriously speaking, this is the way software development has proven to be effective and efficient. But wait, you might say, what about projects that change their requirements from day to day? Think about what was just said. We’re going to build a product that will change from day to day. Might as well build a house out of LEGOs. It will not be a well design product. Imagine if any other industry would do that wing-it approach. Cars that break down once you drive them off the lot because they haven’t been tested properly, even though their internal tests say nothing’s wrong. Imagine having to tweak the car every day or week because new bugs have been discovered. If you want to be serious about the product, know and understand what you’re building. Commit to what you’re building, and build it. Just like building houses. There’s a blueprint for a reason. You draw it, commit to it, then you build based on that commitment. Once you chose to not have a basement, it will be super expensive, and insane to try to add a basement to your house. And all the while the blueprints are being developed, guess what. There’s no house to demo to the owners. There are prototypes and models and artist renderings. Modern day software can make a 3D replica of it on your PC, but the house itself is not actually built. Why is software any different? Why are we not showing software the same level of respect?
When you commit to it, that’s where the fist 33% comes in handy. This is something you’re going to build, not just “wing it”. Yes, I’ve actually heard the phrase to “wing it” in planning meetings, by the director of IT. Flow charts, flow diagrams, user flow design, interactive wireframes, mocks all should be done at this point. The product being built has to be understood. NO CODING! I’ve heard one too many times (but we have to show something). Show the flowcharts, the prototype if you built one, the wireframes, the mocks, everything else. Just don’t code it. There could be the small chance of the project changing direction, and instead of it being something easily built in JAVA, it could be something that could be best built as a web-app.
Another 33% of the time should be spent on actual development. Does this mean that there won’t be questions regarding processes? Absolutely not. There should be questions. There should always be questions, but the amount of misunderstanding is significantly lower. It’s no longer about “should we have a basement or not”, but more like, what paint would fit better with this room because of the light coming in from the Sun. The changes here are minimal, with very little impact. By this point you have to FULLY understand the business logic of the application. In the case of games, you have to understand the user flow, the storyline, etc. If you don’t know what comes into the black box, and you don’t know what you’re supposed to be out of the black box, don’t code! When you do begin coding, you should have all of your flowcharts not only fully complete, but also approved by everyone on your team. But, you say, why would a designer need to look at flowcharts? Well, I say, if there’s a logical process happening, and the “No” response generates a process such as “Display email format error to the end user”, the designer needs to know that he needs to make a mock for that scenario. The copy people (text assets) need to clarify the exact text that goes in that error. The UI person needs to understand if this error will be a generic pop up, an inline element below the input field, or a general error box below the form. So, for something that a “winger” might consider a waste, I just showed you exactly why we need flowcharts discussed by all team members from design, to UI, to product, to copy, and then the developer. And it’s for something as simple as “display error”. Think about the mess of having to re-code your code base because you placed a typical alert box, and then someone comes by and tells you that it should be an inline red text appearing below the input box.
This is why the 33/33/33 rule works extremely well and effective. I have been on too many projects where we spend 150% of the time developing and re-developing, and the rest of your life QAing. No clear scope, no defined requirements, no DOD (definition of done), nothing. It’s ridiculous to think you’re accomplishing anything of good quality this way. For me, personally, I refuse to write code before I understand the product for the same reason a mason refuses to lay down the first brick… carpenter refuses to hammer their first nail… or concrete mixer refuses to pour their first cistern before they get a blueprint. Whatever it is they’re building, it could be a wooden framed house, a military bunker, or a castle. Imagine the waste, or crappy construction if they built their masterpieces like we write code today. Major FAIL!
Let’s treat every project as if it was our own, and treat it with the respect it deserves.
And please, code responsibly.