Look like an expert to the public

"The fastest way to look like an expert in something is to publicly accept the blame for why it doesn't work."

- Philosopher Amin

Amin gone Android

I have partnered up with a friend from CMU. We are writing 5 brand new Android Mobile Apps and competing for VC attention.

We could use extra bandwidth on a volunteer basis from C# or Java developers, awesome graphics artists and mobile app advocates. Contact me if you're interested. Release for all five apps is in about 3 months.

Thoughts on hopeless searches

"When you're drunk, boring dates look attractive. When you're bored, recruiters look attractive. When you recruit... don't be looking for drunks!"

- Philosopher Amin

Thoughts on learning

"Your parents controlled your feature selection during your supervised learning to create a learning model that steers your happiness and now you desperately need to do a periodic stepwise regression."

- Philosopher Amin

Gods are not disposable

I haven't written for a while. However, for the past few months I've come across one of my pet peeves often enough that I had to write about it for therapeutic reasons.

You know what a God class is? In an Object Oriented Programming language, a God class is a single class responsible for absolutely everything.

Developers who create God classes typically come from a purely functional programming background and usually do not think about handling object responsibility in a modularized way. They end up writing one class that, say, gets everything from the database, does a million different complex things with it in ways that nobody can follow through reading, and then magically outputs the results. The code is absolutely not readable. The most difficult aspect of improving a software team with this problem is that when you initially provide the developer feedback about the issue, they take religious pride in how elegantly monolithic and "simple" their conglomerate artifact is.

In a past project I've literally spent 2-3 months of my life refactoring code that a so-called "software architect" had written. I don't enjoy rework, but it was a critical piece of code that every developer had to deal with, so it had to be readable. Despite the code being at the heart of the company's technology, its lack of modularization prevented any kind of unit testing whatsoever. The actual and expected pieces of data compared in testing after re-factorization were as large as the entire database, because no smaller module from before this process could be picked to be tested. The team velocity, in my opinion, was not nearly where it should have been - and the God-Object anti-pattern was one of the biggest contributors.

The followers of God classes argue that it's faster to prototype that way until you're profitable. The sad thing is that this assumption is incorrect. In fact, if you were to compare a God class developer with a modularized code developer about 3 months into prototyping, all you need is a sudden change to the requirements to completely throw the former off balance. A modularized code developer is both more agile and more structured, period.

Regardless of whether you're a software engineer or a manager, try to frequently review code generated in your team. If the typical method tends to be longer than 20 lines of code or the typical class is longer than 500 lines, you must realize that your software operating expenses are going to rise very soon. Do something about it now. Have a talk with your peers. Start gently, but keep at it. Ask them why they think every responsibility has to be handled by one class or method. Explore ways to divide those responsibilities between re-usable modules and conquer the problem in ways that can be understood by any reader. Let it be known to everyone that in the competitive field of software, design requirements are ever-changing, and this: Gods are not disposable.