You’ll always have to deal with memory issues, no matter the programming language. Even with the Java programming language, if the right precautions are not taken, you will have some sort of memory leaks, memory issue, out of memory exception, or heap size problem. I’ve seen two common types of memory issues in every application I’ve worked on.
A common source of memory leaks is global static singleton god object that collects or manages a lot of data, maybe a system cache, object lookup table, service locator, etc. This type of singleton pattern will require other objects to register with it, add themselves to the global pool of objects, but if they are not properly removed, unregistered, when they are no longer needed you will see your memory usage increase over time. I’ve seen this issue when using the callback or listener pattern and the listener object itself holds a lot of other data. This sort of problem is usually relatively easy to identify with a profiler, it will usually be one of the largest objects in your system.
The other, more difficult memory leak to identify, is when you have hundreds of thousands of objects each taking up a reasonable amount of memory. In this case, a single object instance will not take a lot of memory but collectedly the hundreds of thousands of objects can eat up a lot of memory. Here are a few things you can think about when dealing with a small class that spawns thousand of objects…
If you have int types, see if you can change them to short or byte types. Try subclassing if you have any number of properties that most often than not set or are null. Think about lazy loading arrays, lists, and other objects references. If there are many object instances of this class, and any portion of these instances are logically equivalent, think of using the flyweight pattern.
I like to adhere to the AAAA rule of email. The four A’s of email reminds you to check you email for four items before you click the send button. Check and double check for correct Address, correct Attachments, correct Attitude and tone and state an Action you want from a recipient.
Recently, a developer in distress sent the following email to the whole company.
I can’t delete any data from any UI screen.
That test doesn’t read like an email, it doesn’t even make sense as a tweet, it’s like an unfortunate cookie message. The email should not have been sent to the whole team, which include sales people, it is to vague, does not have any clear action or request.
Communication is vital for any team and the teams running on full speed need the right level of communication in the right medium. If you are interested in learning how to effectively use email to communicate with your team I recommend the following posts.
I don’t count my progress by the line of codes but at the same time I don’t take pride by over engineering a solution. Writing code is like writing for a publication, you have to know at what reading level you are writing for. That said, the one type of code statement that gets under my skin is what I call the run-on code statement. A Run-on code statement is one that has multiple method calls in one statement. Here is a made up example of a run-on code statement.
In the above run-on code statement there are four method calls. I’ve seen worse. The reason whey run-on code statements are a pet peeve or mine is that if anyone method call fails because of a NullPointerException or some other error it’s difficult to quickly know what segment of the code statement failed. This is also annoying to debug if you want to step into one method out of the four.
Here is a short clip of Steve Jobs introducing the new Think Different ad campaign which includes the Here’s To The Crazy Ones speech. From this clip, here are my favorite quotes from Steve Jobs.
The Apple brand has clearly suffered from neglect in this area in the last few years and we need to bring it back. The way to do that is not to talk about speeds and feeds; not to talk about mips and megahertz; not to talk about why we’re better than Windows…
Our customers want to know who is Apple and what is it that we stand for, where do we fit in this world. What we are about isn’t making boxes to get people to get their jobs done, although we do that well, we do that better than almost anybody in some cases. But Apple is about something more than that. Apple at the core, it’s core value, is that we believe that people with passion can change the world for the better.
It is easy to be amazed by the accomplishments of Steve Jobs, from starting the personal computing industry, to revolutionizing the music industry, to leading the way on the mobile front. What amazes me everyday is what his innovation has meant to people. How many moments where shared, songs created, emails read, videos edited, photos fixed, homework done, thesis papers written, video calls made, art projects submitted, lives touched because of his work. There is people with disabilities that use the devices he designed, children with autism are learning on iTouch devices, freelance designers and developers are making a career on his platform, industries have been created around his vision. 313 patents is impressive but the number of ways his genius has benefited us all is innumerable.
Processes are supposed to support people, not people support processes. A process should be documented in one document or checklist or directory or wiki or website that everyone has access to. Everyone should have a copy readily available. It should not be outlined in emails or sporadically over several documents across different locations. Always review the process and remove friction. Try to minimize steps when possible, centralize the information, anoint clear responsibilities, build in safety nets, empower developer to make decisions, let it grow as the team grows. Automate the process as much as you can, make reports people can use, make everyone’s progress visible. For some certain teams, there is diminishing returns for adding more processes.