February 19, 2015

So I've been developing an app which has a really big database (for an Android app) and while still in development it has already been upgraded quite a few times.

My team and I have been using the onUpgrade method without any problems for the whole time, but because we use git with one branch per feature and code reviews sometimes the app version that we have installed on our device before when doing a code review is bigger that the one of the next code review.

That isn't of course a problem, we could just uninstall it, as it will never happen in production, but for my knowledge sake, I tried to implement a simple downgrade.. just drop all tables and create them again.

Called when the database needs to be downgraded. This is strictly similar to onUpgrade(SQLiteDatabase, int, int) method, but is called whenever current version is newer than requested one. However, this method is not abstract, so it is not mandatory for a customer to implement it. If not overridden, default implementation will reject downgrade and throws SQLiteException

This method executes within a transaction. If an exception is thrown, all changes will automatically be rolled back.

Parameters

db

The database.

oldVersion

The old database version.

newVersion

The new database version.

Ok, so I've had to override it to avoid an exception. No problem...

... I thought.

In fact the app crashed when I tried to drop all tables and (re)create them on that method... it seemed strange, as it was a lock on the database problem...

February 5, 2015

I've just finished reading How Google Works. It could be just one more of those books about a company that just focus on the stories and on the OMGs how spectacularly awesome this company is, but I was really surprise to find it one of the best books about real management that I've read recently.

It does not focus only on how Google works but why it works in specific ways, providing the background mindset of the management which is a fresh breeze of air on management.

It deprecates the old management style of "I'm the boss and I know everything" to a more 21st century If I hire the best (and I have to give my best to hire them), I'll have to give up some of the pyramidal control in exchange to tap into the power of each of the brilliant individuals that are now working in this company.

I'll leave here some of the parts I've really appreciated:

(Speaking about smart creatives, which is the kind of workers Google wants to hire:) It is also why they are uniquely difficult to manage, especially under old models, because no matter how hard you try, you can't tell people like that how to think. If you can't tell someone how to think, then you have to learn to manage the environment where they think. And make it a place where they want to come every day.

Many people, when considering a job, are primarily concerned with their role and responsibilities, the company’s track record, the industry, and compensation. Further down on that list, probably somewhere between “length of commute” and “quality of coffee in the kitchen,” comes culture. Smart creatives, though, place culture at the top of the list. To be effective, they need to care about the place they work. This is why, when starting a new company or initiative, culture is the most important thing to consider.

Companies come up with elaborate, often passive-aggressive ways to say no: processes to follow, approvals to get, meetings to attend. No is like a tiny death to smart creatives. No is a signal that the company has lost its start-up verve, that it’s too corporate. Enough no’s, and smart creatives stop asking and start heading to the exits.

Twenty percent time is a check and balance on imperial managers, a way to give people permission to work on stuff they aren’t supposed to work on. It helps bring to life the Steve Jobs maxim that “you have to be run by ideas, not hierarchy.

You want to invest in the people who are going to do what they think is right, whether or not you give them permission. You’ll find that those people will usually be your best smart creatives.

Over time I’ve learned, surprisingly, that it’s tremendously hard to get teams to be super ambitious. It turns out most people haven’t been educated in this kind of moonshot thinking. They tend to assume that things are impossible, rather than starting from real-world physics and figuring out what’s actually possible. It’s why we’ve put so much energy into hiring independent thinkers at Google, and setting big goals. Because if you hire the right people and have big enough dreams, you’ll usually get there. And even if you fail, you’ll probably learn something important. It’s also true that many companies get comfortable doing what they have always done, with a few incremental changes. This kind of incrementalism leads to irrelevance over time, especially in technology, because change tends to be revolutionary not evolutionary. So you need to force yourself to place big bets on the future.

Unfortunately, like Jonathan’s failed gate-based product development framework, most management processes in place at companies today are designed with something else in mind. They were devised over a century ago, at a time when mistakes were expensive and only the top executives had comprehensive information, and their primary objectives are lowering risk and ensuring that decisions are made only by the few executives with lots of information. In this traditional command-and-control structure, data flows up to the executives from all over the organization, and decisions subsequently flow down. This approach is designed to slow things down, and it accomplishes the task very well. Meaning that at the very moment when businesses must permanently accelerate, their architecture is working against them.

The tendency of a CEO, (...), is to try to make too big an impact. It is hard to check that CEO ego at the door and let others make decisions, but that is precisely what needs to be done.

We call it the rule of seven. We’ve worked at other companies with a rule of seven, but in all of those cases the rule meant that managers were allowed a maximum of seven direct reports. The Google version suggests that managers have a minimum of seven direct reports (Jonathan usually had fifteen to twenty when he ran the Google product team). We still have formal organization charts, but the rule (which is really more of a guideline, since there are exceptions) forces flatter charts with less managerial oversight and more employee freedom.

“Tom Peters: There is no such thing as a minor lapse of integrity”

If you are now curious, you can have here a little sneak peek about what they talk about on the book.

February 3, 2015

One of my favorite libraries for Android recently has been EventBus. If you don't know what it is, it is simple, according to their own explanation:

EventBus is publish/subscribe event bus optimized for Android.

simplifies the communication between components

decouples event senders and receivers

performs well with Activities, Fragments, and background threads

avoids complex and error-prone dependencies and life cycle issues

makes your code simpler

is fast

is tiny (<50k jar)

is proven in practice by apps with 100,000,000+ installs

has advanced features like delivery threads, subscriber priorities, etc

I've been using it on my Android architecture examples and it works like a charm. The only thing I've been missing is the capability to limit the number or running events and the capability of cancelling them.

So.. I've fork it, and I'm now actively integrating that capability on the library. I'll probably make a pull request upstream to the original EventBus but I don't have any clue if it will be accepted or not.

Anyway... if you find it useful give it a look.. and who knows, give a line or two of code also!