How Can Managers Work More Efficiently with IT?

Would you rather work under someone who is an excellent developer but lacks people skills or leadership capabilities - or for someone that has excellent people skills, communicates well, and is a great leader but has limited understanding of productive coding practices? That’s not to say that the choice is one or the other but in many professional situations it does.

Managing an IT staff comes with numerous challenges, especially if the manager has no previous experience with the coding necessary for completing the project. Managing a business and IT's execution of tasks vary greatly in required skill sets, but it's important to find a cohesive and cooperative middle ground in order to see a project to its end. To fully grasp the intricacies of IT's involvement in the project at hand, managers can do the following to help further their efforts.

Get a basic understanding of coding and technical practices necessary for the project at hand by taking the time to research and practice enough to get a grip on the concept. This will allow managers insight on what their IT folks are really working on daily. Expertise in a programming language is not required, only an overview of the stuff that matters, i.e. understanding the concept of OOP (Object Oriented Programming.) Having this knowledge cannot be overlooked and will gain respect among multiple spectrums in the organization.

In programming, memory leaks are a common issue, and it occurs when a computer uses memory but does not give it back to the operating system. Experienced programmers have the ability to diagnose a leak based on the symptoms. Some believe every undesired increase in memory usage is a memory leak, but this is not an accurate representation of a leak. Certain leaks only run for a short time and are virtually undetectable.

Memory Leak Consequences

Applications that suffer severe memory leaks will eventually exceed the memory resulting in a severe slowdown or a termination of the application.

How to Protect Code from Memory Leaks?

Preventing memory leaks in the first place is more convenient than trying to locate the leak later. To do this, you can use defensive programming techniques such as smart pointers for C++.  A smart pointer is safer than a raw pointer because it provides augmented behavior that raw pointers do not have. This includes garbage collection and checking for nulls.

If you are going to use a raw pointer, avoid operations that are dangerous for specific contexts. This means pointer arithmetic and pointer copying. Smart pointers use a reference count for the object being referred to. Once the reference count reaches zero, the excess goes into garbage collection. The most commonly used smart pointer is shared_ptr from the TR1 extensions of the C++ standard library.

Static Analysis

The second approach to memory leaks is referred to as static analysis and attempts to detect errors in your source-code. CodeSonar is one of the effective tools for detection. It provides checkers for the Power of Ten coding rules, and it is especially competent at procedural analysis. However, some might find it lagging for bigger code bases.

How to Handle a Memory Leak

For some memory leaks, the only solution is to read through the code to find and correct the error. Another one of the common approaches to C++ is to use RAII, which an acronym for Resource Acquisition Is Initialization. This approach means associating scoped objects using the acquired resources, which automatically releases the resources when the objects are no longer within scope. RAII has the advantage of knowing when objects exist and when they do not. This gives it a distinct advantage over garbage collection. Regardless, RAII is not always recommended because some situations require ordinary pointers to manage raw memory and increase performance. Use it with caution.

The Most Serious Leaks

Urgency of a leak depends on the situation, and where the leak has occurred in the operating system. Additionally, it becomes more urgent if the leak occurs where the memory is limited such as in embedded systems and portable devices.

To protect code from memory leaks, people have to stay vigilant and avoid codes that could result in a leak. Memory leaks continue until someone turns the system off, which makes the memory available again, but the slow process of a leak can eventually prejudice a machine that normally runs correctly.

Related:

The Five Principles of Performance

In Demand IT Skills

I will begin our blog on Java Tutorial with an incredibly important aspect of java development:  memory management.  The importance of this topic should not be minimized as an application's performance and footprint size are at stake.

From the outset, the Java Virtual Machine (JVM) manages memory via a mechanism known as Garbage Collection (GC).  The Garbage collector

• Manages the heap memory.   All obects are stored on the heap; therefore, all objects are managed.  The keyword, new, allocates the requisite memory to instantiate an object and places the newly allocated memory on the heap.  This object is marked as live until it is no longer being reference.
• Deallocates or reclaims those objects that are no longer being referened. 
• Traditionally, employs a Mark and Sweep algorithm.  In the mark phase, the collector identifies which objects are still alive.  The sweep phase identifies objects that are no longer alive.
• Deallocates the memory of objects that are not marked as live.
• Is automatically run by the JVM and not explicitely called by the Java developer.  Unlike languages such as C++, the Java developer has no explict control over memory management.
• Does not manage the stack.  Local primitive types and local object references are not managed by the GC.

So if the Java developer has no control over memory management, why even worry about the GC?  It turns out that memory management is an integral part of an application's performance, all things being equal.  The more memory that is required for the application to run, the greater the likelihood that computational efficiency suffers. To that end, the developer has to take into account the amount of memory being allocated when writing code.  This translates into the amount of heap memory being consumed.

Memory is split into two types:  stack and heap.  Stack memory is memory set aside for a thread of execution e.g. a function.  When a function is called, a block of memory is reserved for those variables local to the function, provided that they are either a type of Java primitive or an object reference.  Upon runtime completion of the function call, the reserved memory block is now available for the next thread of execution.  Heap memory, on the otherhand, is dynamically allocated.  That is, there is no set pattern for allocating or deallocating this memory.  Therefore, keeping track or managing this type of memory is a complicated process. In Java, such memory is allocated when instantiating an object:

String s = new String();  // new operator being employed
String m = "A String";    /* object instantiated by the JVM and then being set to a value.  The JVM
calls the new operator */

Recently, I asked my friend, Ray, to list those he believes are the top 10 most forward thinkers in the IT industry.  Below is the list he generated. 

Like most smart people, Ray gets his information from institutions such as the New York Times, the Wall Street Journal, the Huffington Post, Ted Talks ...  Ray is not an IT expert; he is, however, a marketer: the type that has an opinion on everything and is all too willing to share it.  Unfortunately, many of his opinions are based upon the writings/editorials of those attempting to appeal to the reading level of an 8th grader.  I suppose it could be worse.  He could be referencing Yahoo News, where important stories get priority placement such as when the voluptuous Kate Upton holds a computer close to her breasts.

Before you read further, note that missing from this list and not credited are innovators: Bill Joy, Dennis Ritchie, Linus Torvalds, Alan Turing, Edward Howard Armstrong, Peter Andreas Grunberg and Albert Fent, Gottfried Wilhelm Leibniz/Hermann Grassmann ... You know the type:  the type of individual who burns the midnight oil and rarely, if ever, guffaws over their discoveries or achievements.