Monthly Archives: December 2014

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.

I’ve been playing around with CodeIgniter, and although I’m not a huge fan of 3rd party PHP frameworks, I would have to say that CodeIgniter is probably the easiest out of the box solution. Of course, I still have to build everything that I need for it. It’s not like it comes with an image cropper, or a customized user profile area already built, but for its MVC structure, it’s pretty decent.

I’ve recently started to dabble in its query-ing capabilities. Although I like writing sql queries out by hand, and yes, insert them into my PHP code (model files under my models folders), what it has is a decent enough, and simple way to do get and set some data. Not bad… Until you come up to a query like this:

At which point… why even bother to use an ORM, or DAO? You’re just going to mix up your code anyway… Stop trying to write everything in PHP. MySQL is powerful as is without abstract layers.

Anyway, that’s one point. The other is all of the session and cookie handing.

Why load an entire new class, object, etc like $this->load->library(‘session’); when all you really need is $_SESSION. Done! All for the purpose of writing saving some additional info that you rarely use, or can gather any other way? I suppose it’s a shortcut that needs to be learned, but PHP already does that in its way.

The best feature, which it took a little convincing, was its MVC structure. Although I like to develop modularly (MVC structure should be kept in modules, not in the entire site), I was ok with its structure, considering that I can build folders for all of my “modules” but then I would have the same module folder in three different places.

The routing for it was something that was all right. It didn’t wow me. Basically, we took htaccess rewrite conditions and converted them into an array… Sigh… 6 of a kind, half a dozen. htaccess is faster though if you want to talk performance.

So in finale, it was probably the easiest to pick up and go with, considering its learning curve and its openness to be more like PHP.