Wednesday, April 30, 2014

Projects versus Operations: where Gold plating fits

Simply put, in project management, Gold Plating "refers to the addition of any feature not considered in the original scope plan". PMI actually red flags gold plating as being a bad practice (PMBOK Guide). I agree. In a "project context" it's a bad practice to do something that's out of scope and not included in the project plan. That simple.

However, in an "operations context", I'm a fan of the "Deliver more than expected" mindset (Larry Page). If, on your day-to-day normal operation, you have a small time window to go beyond what's required, DO IT!

Suppose your work is to monitor a farm of specific apps or whatever. You saw an opportunity to improve your daily work and, as expected, you develop a tool to ease your life. Cool, just normal work. BUT, if you can go further on and build a small documentation and make it available to all the company, BETTER. If it's so good and you can pitch it to another client with similar environment, amazing. If another client (and another, and another...) ends up buying it, PERFECT!

So,
    – In Projects: "Deliver as expected".
    – In Operations: "Deliver more than expected".


Friday, April 11, 2014

OutSystems: A Good Example!

OutSystems is an extraordinary platform (made in Portugal). If you Reverse Engineer their code, you can see some really amazing uses of the .NET capabilities (even WeakReferences and the idea of WeakDelegates). Pretty cool.

Here's a good example:
Converting a string value to a decimal can be done using an OutSystems Built-in function just like below:

(click to enlarge)


But, as you can see in the debugger, converting 223,6 to a decimal goes wrong. Why? Well, if you reverse engineer the code from the OutSystems Platform you end up with the TextToDecimal function:

(click to enlarge)


They use the "long version" of the Decimal.TryParse method. And that's the good example. By using it, they made the TextToDecimal CultureInvariant. That is, not dependent on Machine configuration. It's culture-insensitive. So, invoking the reverse engineered method actually yields similar result as expected. The "dot" version converts, the one with the comma doesn't:

(click to enlarge)


Now, my machine's current culture is Portuguese:

(click to enlarge)


So, using the short version of Decimal.TryParse doesn't behave as the above:

(click to enlarge)


As you can see, it's the opposite of the first version presented above. This is because my current NumberInfo understands the comma (,) as the decimal separator.

(click to enlarge)


And according to the MSDN documentation, when using the no culture constructor, the CultureInfo (and NumberInfo) defaults to the CurrentInfo:

"Parameter 's' is parsed using the formatting information in a NumberFormatInfo object initialized for the current system culture. For more information, see CurrentInfo."

This second version represents problems. Imagine your machine is pt-PT but the production environment is en-US. Bad out come.
Extra point to OutSystems. A case of good development.


Thursday, April 10, 2014

The mobile app economy is far from open

Shamelessly quoting Mark Cuban:

"I bet you think the mobile internet is open. That if you write the next great mobile app there is nothing that can stop it from fulfilling its destiny. That if you create a mobile content app that blows away netflix there is nothing that can stop it. Wrong!"

Interesting thought. You can read the full article here.