Gaming PC Builder Challenge, pt 1

A former co-worker/student/underling texted me out of nowhere late this afternoon. At first I thought he was going to inform me that one of my programs blew up and I’ll have to go to the office to fix it. Fortunately it wasn’t the case (on the contrary, he informed me that my program was bug free all this time… riiiiight) and he was just asking for suggestions on building a gaming PC with PhP 50k.

I’m bored so what the hell. Here’s my take on building a system with that budget.

This first post will be partida*: I won’t be using parts from PCO, PC Hub or PC Express. Instead, I’ll be using parts from VillMan Computers. Their parts are more expensive and they have a narrower range of products, but as Lex mentioned, their customer support is better.

Think of this post as the safe approach in building the gaming PC.

Continue reading “Gaming PC Builder Challenge, pt 1”

Going Back 5 Years…

June 16 came and went last week without me realizing that it would have been my 5th anniversary in my former company had I not departed from it. Not that I had a reason to remember, though.

However, once I had realized it, I couldn’t help but ask myself the question:

If you would go back five years in the past, what advice would you give your past self?

Continue reading “Going Back 5 Years…”

Code Comments

Code Comments: novice programmers either use too much or too little, while so called “experienced programmers” don’t even know where they should be placed.

Actually, the proper use of code comments is one of the issues in software engineering with the least amount of debate. Overall, there are only two rules of thumb to keep in mind when using code comments.

Comments should explain the why instead of the how or what.

In other words, your comments should not repeat what the code is saying. Code Complete uses these two examples:

//set product to base
product = base;

//loop from 2 to "num"
for ( int i = 2; i <= num; i++ ) {
    //multiply "base" by "product"
    product = product * base;
}
System.out.println( "Product = " + product );
//compute the square root of Num using the Newton-Raphson approximation
r = num / 2;
while ( abs( r - (num/r) ) > TOLERANCE ) {
    r = 0.5 * ( r + (num/r) );
}

System.out.println( "r = " + r );

Both code snippets don’t look good (i.e. the variable names are bad). However, only the latter’s comments are useful, and the former would be better off with no comments at all.

If the code is so complicated that it needs to be explained, it’s nearly always better to improve the code than it is to add comments.

There are many ways to do this, ranging from using more descriptive variable names to inserting white space when needed. My personal favorite is to extract methods.

...

//get user input
...

//process user input
...

//format and display output
...

In this case, the programmer crammed all of the logic into one function. This usually happens when the developer reached his state of “flow” and just keeps on typing hundreds of lines of code into the system. The problem with functions longer than a couple of dozen lines is that not only is it hard to read, it’s also hard to debug.

By extracting the logic of the comments, we can have clearer code without even using comments, not to mention an easier to debug program:

public void run() {

	getUserInput();

	processUserInput();

	displayOutput();

}

private void getUserInput() {

	...

}

private void processUserInput() {

	...

}

private void displayOutput() {

	...

}

And yes, this is post is a lame excuse for trying out the SyntaxHighlighter plugin. :P

Waterfall Model

Waterfall Model

Anyone who has taken a software engineering course or has experience in developing software for clients should be familiar with the diagram above. It’s the infamous waterfall model, the approach in software development where projects are split into distinct phases connected serially to each other.

What most developers, managers, and clients who blindly use the waterfall model don’t know is that the 1970 paper that introduced that model (without naming it)–Dr. Winston W. Royce’s “Managing the Development of Large Software Systems“–is ironically a criticism of the model. Zooming in on the text below the diagram:

I believe in this concept, but the implementation described above is risky and invites failure.

The rest of the paper then tries to provide possible ways to mitigate the risks involved in the model. I personally don’t agree with some of his recommendations, but this paper is almost 4 decades old so I’ll let them slide.

I am not saying that the waterfall model is a useless approach to software development. It actually a “best practice“; there are some projects that are better off done using the waterfall model or its derivatives.

As expected from best practices, however, people tend to think that the waterfall method is the best way to produce software regardless of context. I’m fairly confident that this misuse of the waterfall model is the root cause of most failed software projects. Thus, it is imperative that software developers should be familiar with both the risks involved with the waterfall model, as well as the alternatives to the waterfall model in case the risks are too high.