Archive for July, 2010

Reducing Learning Curve Overhead with OOP

Monday, July 19th, 2010

A lot of people don’t understand why object-oriented programming (OOP) practices are getting so much hype. While I can’t explain all the benefits of using OOP in this article, I will cover one of the compelling cases of using OOP, you save time.

Imagine a scenario where a new recruit has just joined your ranks. He was hired into your team to speed up your project. If your code wasn’t designed in an OOP manner, then he’ll most likely have to review a good chunk of the code in order to figure out what’s going on and how the various pieces interconnect. Some code at line 23 might be affecting line 83. Some function might take 2 integers and behave one way, and then take in 3 arrays and behave another. The code might also require certain global parameters to be set in a certain sequence before things can function.

In OOP programming, things you don’t need to know, you don’t need to know. For example, if you were coding a shopping cart, the “scanning system” only cares to know about the price of the item. The “product” object only needs to know it’s “price”. The “shopper” only cares about the price and the total. Each of these objects can have various complex behaviors, but they’re all encapsulated within the object. For example if the “product” was perishable, and price was a function of it’s expiration, the “scanning system” and “shopper” doesn’t need to know about this. If you were to adjust how various item’s price fluctuates, you only need to focus on “product” classes.

Whereas, in a non-OOP class, you might a very long file, class, or function, and it might be filled with all these complex checks to figure out how much the price is, but in an OOP system, the “scanning system” simply asks the “product” for it’s price. OOP code is also more intuitive, since OOP mimics real world objects and relationships.

OOP practices are good to adopt, although there is some overhead, there will definitely be long-term savings in more ways than one.

Code Obsolescence

Friday, July 9th, 2010

I believe that code-base no matter how well written are doomed to the fate of eventual obsolescence. No matter how well the code is constructed, there are bound to be unforeseen edge cases that can have a minor or major impact on your code. If your business  decides to take the code to a whole different level, you might need additional functionality that the code-base didn’t account for. “The best laid plans of mice and men oft go astray”. Businesses need to plan for this case, and allocate the resources accordingly.

It’s possible for your code to absolutely perfect and NEVER EVER require change. You might even conclude it might be a Microsoft only thing, but think about it this way. How often has Microsoft, Apple, Linux, Facebook, Myspace, and Google changed their code? Quite often, it’s almost like every few years, some major change occurs. Windows XP was recoded into Vista, and Windows 7 was Windows completely recoded from the grown up. Changin not only the look, but the security and functionality.

Code changes because they business requirement changes. Business requirements change because the customer’s demands change. Time changes a lot of things. So you have to ponder, if your code-base is an exception to the rule. Chances are, it’s not. If you don’t plan for the team to completely recode the code-base every few years, then you’re going to force yourself into an immobile position where your customer’s demands have changed, but your business  can’t respond to accommodate it.

With each new core product system, you should keep track of how long it took to develop it, make sure it’s well documented, and budget some time in the future to reallocate this amount of time to reinventing it. Yes, reinventing. Is this a direct violation of the DRY principle (Do not Repeat Yourself)? No. If it was exactly the same product, sure, it’s a violation, but since you’ve introduced new parameters, the no. Do you use the same method to do single-digit against single-digit multiplication as you do double-digit vs. double-digit, triple-digit and so on? No. Code should be no exception, plan accordingly, or face some interesting crossroads in the lifetime of your business.

Cultural Value of Employees

Wednesday, July 7th, 2010

After watching a few departures from my company, I have come to realize the cultural importance of employees. Each employee contributes in their own way to the company in terms of work ability and cultural value. When an employee works for a company, they’re working for the company because they believe in the company’s product line, they enjoy the development environment, and they feel like they’ll contribute to the company while growing with the company.

When an employee leaves a company, they not only reduce the total work capacity of the company, but they also reduce the cultural value. The benefits received by other employees will definitely be diminished. Sometimes this loss is small, sometimes it’s great, and sometimes they might even have something to gain.

When an employee leaves, it starts a snowball effect. If any of the employees were on the fence about leaving the company, this indicates that marginal benefit is equal to marginal cost. If marginal benefit is a factor of cultural value, then this would imply marginal cost now exceeds marginal benefit. Thus, that other employee leaves. Then people who are affected by employee 1 plus employee 2’s departure will now depart and etc.

In order to avoid this, the company will then have to increase the marginal benefit the remaining employees to stem the snowball effect. You can probably even measure the cost of the cultural value of the employee by how much money you’ll have to spend to keep the remaining employees on board. This effect is greatest if you have a large employee base, and the employee has a great effect on other employees. If an employee is leaving, you’ll definitely have to take these things into account before quickly dismissing him. If possible prevent the departure of the employee altogether, if not pray that you’ve done the cost-benefit analysis correctly otherwise the fate of your company might be at stake.

Underlying System Flexibility of API Testing Systems

Thursday, July 1st, 2010

Your testing sandbox can be flexible or immutable. I have a preference for designing testing systems that are flexible. Data that is generated via the testing process, can be modified through the testing process. Everything flows the same as a live system from beginning to end. There are developers who would disagree with this approach, such as we’re giving the testers too much control that can allow testers to generate cases we didn’t expect, which can cause some amount of embarrassment. Another argument is that with fixed data, we don’t have to worry about as much, since we pretty much control the entire flow. While the counter-arguments have a legitimate point, I would argue that their limitations defeat the purpose of a testing system.

A testing system should be a sand-box, as in implied in the term “sand-box”, testers can play around with it as much as they want. If we made the data immutable, it’s not really a sand-box, but more like buttons. If a person relying on your system have a lot of unique demands on your system, your system will not be able to handle it without changing code or system structure. In fact, you’ll need to implement a whole layer just to handle the immutable data and how to handle the response. If you were to allow the system to be flexible, and the objects mutable, or changeable, there will still be layer, but that layer will be deeply tied to existing components, which will still allow existing components to be tested. While the first case, although you can still have existing components tested, such testing is pointless, since you’re forcing a set response to a set data set each time.

Flexible testing systems allow you to fulfill the demands of any tester easily, since they’re pretty much testing how their system interacts with your system, and it closely mimic normal behavior. Not only that, but it also allows testers to test your system for flaws, helping point out flaws in your system before the flaw does any major damage. In an immutable system, we don’t have to worry about edge cases we didn’t account for. Which can be great, but unfortunately, a flexible system can handle the tester’s system that was design to deal with immutable or mutable data. In an immutable system, if the tester wants mutable data, we will pretty much junk the existing system and create another one. Turning a flexible system immutable is easy, turning an immutable system into a flexible system is hard. Much like procedural code versus object-oriented code, procedural code is pretty rigid, but object-oriented code is pretty flexible. “Be water, my friends.”