Speeding Up Technology: Cultivating Leaders

Most people understand leadership as power and/or authority and there is a lot of talk about the "strength" and "vision" of a leader. However, it is easy to mistake bullying & stubbornness for strength and demagogy & rhetoric for vision. The difference is too subtle and short-term results too similar to cause any alarm.

The generally accepted way to make a new product at greatest speed is to place some brilliant developers under an able Senior Manager or Product Architect. Now, it can take two directions from this basic set up. One way is that the manager just focuses on the current product and executes the project in the style of "Command and Conquer" by making things simpler for his team and spelling out clear instructions to execute the project. If the team struggles, he dives right in and leads from the front ensuring the correct course for the ship. All sailors learn a lot by seeing the able captain in action and there is tremendous growth. He can encourage his sailors to learn and grow.

All is happy in the world till the point, till one of the sailor learns enough to attempt to captain the ship, perhaps a smaller ship. The captain may view it as abject desertion or, worse, covert mutiny. Or he may provide the testing ground for the willing sailor as he knows that the company will eventually have many ships and he cannot steer all of them alone. In this context, the vision and growth strategy of company assumes paramount importance. If there is no growth potential, it will definitely be either desertion or mutiny (with accompanying unpleasantness). Else the business will gain another leader and grow.

This also makes further demand on the captain to actively recognize, cultivate and have an outlet for promising young sailors. Else he should hire sailors who do not harbour such ambitions and are happy sticking their nose only to their immediate work. Since no company can provide an unlimited supply of opportunities, one has to be ready to let go of talented people if they cannot neither find optimum use of the same nor think of ways to cultivate them further.

A company trusts only the best to build the nuts and bolts of their product. If it cannot make a strategy to retain them, it is a shame. This can not only lead to loss of talent but can also disrupt progress of the product due to loss of expertise and problems associated with hiring. Hence, it is in the best interest of the project to give a thought about this before starting. Here, as I said, the vision and policy of a company may be the ultimate deciding factor. At least in the initial life of a company, an entrepreneurial team that generates more entrepreneurial teams can be a powerhouse of growth and innovation. That it will affect speed positively over the long run is but one of the many side-effects of a well-thought and flexible company policy.

Speeding Up Technology: Ambition with Vision

Till this point we talked only about technology and its impact on the project without taking into account the manager, the leadership and the company. These elements bring in the human element and its pitfalls to the job. For this one reason, I feel behaviour sciences need to be explored more not only wrt economics but practically all domains of management. My articles do not claim to be any authority but reflect my point of view developed by working, reading and observing.

In our first article we talked that from managerial point of view, the main stumbling blocks can be:

• poor choice of technology
• poor choice of development methodology
• lack of focus on long-term vision with complete focus on speed

We shall explore them. But even before that, a lot depends on the company vision and the corresponding leadership policy.

Company vision defines the existence of a corporation. Why does the corporation exist in the first place? How ambitious and flexible is it towards growth? I have seen a lot of family and privately owned businesses stagnating as their sole purpose is to earn money for its owners, as a stable source of income or to do some limited good work in its sphere. There are yet others that come up due to the Government's policy changes and new legislation or those that manage to entrench themselves in a monopolistic niche. One thing strikingly common is that many of these ventures aim to neither be the "best" nor have a long term growth plan. There is no vision to the ambition. In Jim Collins words, these are companies who have figured out a way to be good but have not thought of being great by choice or chance. In cases when they do, some truly amazing companies or professions result from that.

The problems, to name a few, that arise from company's lack of vision for its growth are as follows:

• A small company does not have any use for too many leaders. This would generally translate into a senior rung of management with a big vacuum beneath. This can blow in the company's face in time
• Lack of growth will ultimately frustrate ambitious & able executives and employees alike, who may ultimately leave for better avenues. This is especially true for the Sales force
• A "family" atmosphere and nepotism can take roots more easily in a family run enterprise, seriously affecting the company's long-term future
• Ultimately competition will come calling, and if they are growth oriented, it will prove disastrous for the parent company

Having said that, there are some advantages to be had by working for a small company in its setting up phase:

• it will give you the opportunity to interact with and witness all aspects of business. This may prove critical in your growth as a leader who has a strong general awareness
• you get to see the whole product development lifecycle very closely, again adding to your leadership potential
• if (a big if) you can affect the company to make the leap and it succeeds, the dividends are yours to have
• in the initial growth phase learning is very profound and comprehensive due to the chaos associated with starting a venture, these things may be hard to learn in any big company and will serve you well when you want to do something on your own

Summarizing, in general limiting of vision ultimately reduces the company's efficiency and affects its supply of leaders. This is true at least for the technology industry where change is too rapid for comfort of the conservative. Ambition with vision can be the currency of speed. If your employees know that they are not a "cog in the wheel" but are actually contributing to something important that will affect at least their lives positively, it will help to speed up work and check attrition. A good work-life balance, an understanding manager, "just" compensations and good employees facilities can be the icing on the cake, but it is not the cake that can satiate the hunger. I feel that nothing can replace the electric, palpitating combination of vision and ambition.

Speeding Up Technology: Testing

Nothing can replace good development, and a good unit testing is a part of good development. I will not go as far as recommending hardcore test-driven development, but robust unit testing never hurts.

Pre-JUnit, having a "main" method in every Java class to be tested was the way I went about testing. In came web applications and testing this way suddenly felt difficult. Then a combination of JUnit, JMock and Spring enabled me to test my code more meaningfully. For multi-threaded systems where even debugging into the running code is virtually impossible and Unit testing can help only so much, intelligent use of logging can help a lot to both verify functionality and spot potential bugs.

Change is our constant friend, and unit tests enable your team to keep track of their key assumptions and all the parts of the code affected by any change in the code. Barring this, the team will inevitably waste time due to avoidable, simple bugs. This makes more sense as a company cannot be sure about who will change the code in future. Documentation, code-comments and well-written code can help a new developer to understand many things, but none of them can replace well-thought unit tests that capture the essential purpose, assumptions and functionality of the class in a very practical way. It also helps the developer to think about his code more deliberately and deeply. Overall, this adds to efficiency gains in terms of product development speed and code quality.

Speeding Up Technology: Choosing the Right IDE

People who were born with 'Eclipse' in their hand may not be able to appreciate the woes of a programmer trying to be productive with 'Edit Plus' or 'vim'. Many managers grossly under-estimate the productivity gains that can be had by using the right IDE. Not only that, development productivity for many current technologies can be improved significantly if their IDEs see significant improvement.

If you do not mind spending, go ahead and buy 'Idea'. If you are broke, 'Net Beans' would make a very good choice. I know a lot of people would be screaming 'Eclipse' by this point of time. 'Eclipse' is, no doubt, the IDE with greatest potential. But if you are developing a web application, want to get up-to-speed asap and integrated with most of the needed Java and J2EE technologies for the project(Maven, Subversion, Database, Servers, Messaging etc.) in no time, I would recommend 'Net Beans'. If you value super customization over speed, 'Eclipse' is your baby. Eclipse can also serve as a fabulous starting point for anybody who wants to develop an IDE.

The tricky bit will come into play if you wish to develop a rich internet application. This would certainly need either JavaScript or Flex. Personally, I feel that there is no IDE that effectively addresses this problem of building a super-efficient dashboard on top of a Java based backend. In this case I would recommend using Eclipse because the Flex IDE is built on top of Eclipse. You may even use Net Beans and Eclipse in conjunction while you take time to configure Eclipse to do the complete bidding.

Speeding Up Technology: Reinventing The Wheel

Re-usability is the holy-grail of any large-scale production industry. IT is no different. This re-usability primarily manifests itself on the technical front in form of programming paradigms, reusable components and frameworks.

Programming Paradigms

Programming paradigms include computing concepts like algorithms, data structures, object oriented programming, aspect oriented programming, design pattern et al. These are fundamentals that enable programmers to 'reuse' experience. It is surprising how many developers are unaware about these things. If the team has any member who completely lacks this knowledge, training or replacement is in order as these are probably the basic pre-requisites for hiring.

Reusable Components

Reusable components can be taken from open-source communities, licensed from third party or developed in-house. In open source, Google and Apache Foundation are perhaps the biggest and most reliable contributors. There are also a lot of third party development houses that may have developed the needed components and can save the company a lot of time. It is always a good idea to not only be aware about these initiatives but to actively track them. Joining organizations like Association for Computing Machinery and attending technology seminars can help in keeping you aware and agile. Buying a library, using an open-source library or building on a tried and tested library are acceptable, and even desirable, ways of speeding up development.

Developing reusable components in-house, however, is a more tricky business. Each company, knowingly or unknowingly, does try to build upon what it knows. It is a good start but can never be enough. What is really needed is an active initiative to consciously try to build components, if not frameworks, at each step. A forum to share best practices and components across the company can multiply the benefits and speed up development significantly. In fact, bigger the company, more the benefits. The only point to be kept in mind is that this initiative should neither detract nor confuse the main objective of building the product. The danger of "initiative" turning into another bureaucratic process is an equally scary scenario.

Frameworks

The final component is using frameworks. We have seen Ruby-on-Rails, Struts, Spring et al assuming significant importance. Most of them are practical implementation of programming paradigms and demonstrate the effectiveness (and weaknesses) of the underlying paradigms. Hence, frameworks are at one higher level of abstraction than either the programming paradigms or the components. This means that efficiency gains can be significantly higher if the framework is chosen correctly. In my experience, Spring makes an excellent choice for complex, multi-tiered web applications.

In our next article we talk about IDEs.

Speeding Up Technology Projects

Speeding up technology projects can be done in various ways. I feel that there can be two fundamental stumbling blocks: technological and managerial.

Technologically, I assume that the team has hired reasonably bright developers with a decent, if not perfect, understanding of programming basics. After that,the potential bottle-necks can be:

• reinventing the wheel: programmers spend way too much time doing stuff that is already done by somebody
• IDE: a good IDE can significantly speed up the speed of development
• poor testing

From managerial point of view, the main stumbling blocks can be:

• poor choice of technology
• poor choice of development methodology
• lack of focus on long-term vision with complete focus on speed

These may be self-evident to most of you who have had some experience in IT. Nevertheless, each point is much more complicated than it appears and merits some discussion.

These issues can come to haunt a team at any point due to the extremely dynamic nature of information technology. To be ever-vigilant is the only answer. What makes it especially challenging is the fact that many problems can persist themselves without making themselves evident for a long time; and by that time the rot has set in with a vengeance and changes are pretty hard to implement. In a series of articles I shall have a closer look at these issues in perspective of my experience and observations and chronicle the same. Please feel free to give your feedback and views wrt same.

Specifying SSL Certificate and Keystore Location & Password

A small reminder about how to configure the location and password for your keystore with Tomcat. By default Tomcat will look for your keystore (with the file name .keystore) in the home directory with the default password. It is possible to change the filename, password, and the location that Tomcat looks for the keystore by configuring the SSL Connector in "server.xml" (in conf folder in tomcat). "keystoreFile" is the parameter specifying key location and "keyPass" would specify the corresponding password. the finished config may look something like:

<Connector port="8443" 
    protocol="HTTP/1.1" SSLEnabled="true"
    maxThreads="150" scheme="https" secure="true"
    clientAuth="false" sslProtocol="TLS" 
    keystoreFile="/home/user_name/my_domain.key" 
    keypass="my_keystore_password"/>

This, however, will not help you if you are using an SSL socket. This is just for making an https connection. If you want to control only keystore and truststore name and password for your socket, you need to give the system properties the values by either specifying the same in vm parameters or setting it in the code:

Using VM parameters:

-Djavax.net.ssl.keyStore=keystore.jks 
-Djavax.net.ssl.keyStorePassword=abc123 
-Djavax.net.ssl.trustStore=truststore.jks 
-Djavax.net.ssl.trustStorePassword=abc123

In Code:

Properties properties = System.getProperties();
properties.put("javax.net.ssl.keyStore", keyStoreName);
properties.put("javax.net.ssl.keyStorePassword", keyStorePassword);
properties.put("javax.net.ssl.trustStore", trustStoreName);
properties.put("javax.net.ssl.trustStorePassword", trustStorePassword);

For a better understanding of SSL Sockets, please refer to the JSSE Reference Guide. Nevertheless, this is not the end of your woes if you want to control the location as well. This would make sense if you wished to package your application with some default stores so as it can potentially work right out of the box. Here is a piece of code that can help you to do exactly that: Managing store locations