Archive for February, 2010

CTO versus Architect

February 4, 2010

A software architect is a person who is responsible for setting the road map for his company’s software. A CTO is an architect with a twist; he is restricted by another factor: the bottom line. While the architect is enthusiastic about new technologies and gets excited about new and cool tools, the CTO must balance that excitement with the deliverability of his department and not get blinded by the colorful display of those technologies. It is much tougher to be a CTO than an architect because you have to resist all temptations. The use of dynamically typed languages is pretty cool and hip, but if the application relies on many users effectively using those dynamic behaviors, you may end up gambling with your bottom line by risking your application being untestable.

For an architect, cool technologies must also not be advocated just because they are cool. However, it is much easier to get lost in those feelings when emotions fly high for the very scene of those cool technologies. As an architect, you are loyal to advancements in technologies. A CTO is loyal to the company. A CTO is not a better person than an architect, he just has more incentives in the company than an architect does. Adding more programmers may affect the bottom line (more cost), but to an architect, it is a great opportunity to explore another technology or tool. You may argue that that may not be a bad thing, and may actually help the company in the long run. That is what an architect would argue anyway.  Exactly, that is why I said a CTO’s job is tougher not because he has to have the outlook of an architect only, but also consider the opportunity cost of where else the money could have been spent to maximize ROI. As if this is not enough, he further has to evaluate the business risks that mount due to flirting with new technologies. Using cutting edge technologies may be cool but not necessarily a wise business decision if it introduces slower development, riskier code in production, harder to unit test code, etc.

There is a reason why a CTO should be a big part of the top management of the company. She is enforcing policies and budgets to protect the bottom line, while ensuring R&D is not suffocated. It is very important for the CTO to become extremely well aware of the financial flexibilities that she has as opposed to “budgets” because she should be responsible enough to handle such flexibility. She should be taking out of the basket what she thinks is needed or good enough to optimize the margin of ROI while continuing to give her company a competitive edge in the market.

Don’t be a technology slave

February 4, 2010

Technologies are tools to solve a problem, and not the end goal. I like to think of a technology as a screw driver used to assemble the product rather than the finished product itself.  As a computer scientist, we are problem solvers, and not poets of a certain language. Otherwise we would just be called code entry experts.  Understanding a problem and outlining a solution should come before selecting the technology.

I hear many people say that they hate Microsoft products. Some hate Google’s web API. Some don’t like Java because it is “too OS independent”. Etc. To me, that sounds like someone was trying to pick their screw driver before having a look at the screw itself. As a developer, you need to listen to the problem, and understand the solution, before picking the technology. A technology is supposed to help you implement your solutions faster and more efficiently, and not feed into your love for that particular technology. You should be failthful to the concepts you were taught to balance such as speed, memory, productivity, comfigurability, etc. You should not be faithful to a technology per se. There is a reason why new technologies come about more frequent than corruption scandals in Chicago politics. That’s because the problems in the enterprise are becoming more complex and demanding as businesses become more competitive.

So, pick the technology that best suits your implementation requirements. Don’t let your pre-choice of technology dictates how you implement your solution. When I want to create a simple website that is not highly interactive, simple HTML with JavaScript and CSS would do. If I want some powerful Ajax capabilities with high end UI but all done with quick turnaround, then gwt may be a good choice. I like Java for backend processing due to the endless frameworks and third party tools that support it. But when I want to create powerful desktop applications where the UI is a major focus then .NET would be competitive here although Java’s swing with all of its latest desktop integration and support can be very competitive. I used Fortran 90/95 on a project for Argonne National Lab where speed requirements to process highly complex numerical equations make the word “Java” a racial slur. When I wanted to find a technology to best implement rule-based flow and processing for MedCPU, I chose to use Drools as our rules engine rather than choosing to push for in-house Java implementation of what would have been re-inventing the Rete wheel.

Many times developers don’t see an inherent support by their master (pre-selected technology) for their chosen implementation. So, they fix a bad choice with a complicated decision by selecting to create an API to provide the tools necessary to implement the solution. This is the equivalent of playing with the screw driver end to make it fit the screw. Surprisingly, as anti-commonsense this may sound, I have seen it done more often than replacing the screw driver alltogether to find a more suitable one for the screw.

Now, life is not that easy or straightforward. Most of the time a developer is limited to a pre-screened or selected set of technologies. She has no choice of selecting a screw driver when all she is given is one or two before anybody knows the type of screw they will encounter. Who is at fault here and how the hell is she supposed to put the screw tight in place when she is not allowed to think outiside of the box (toolset box)? I think it is the responsibility of the architect of the system to understand the big picture of all potential problems to see and select a good set of representative tools for his developers. This may not be as easy as it is said above. However, there are plenty of ways to mix technologies in today’s applications than say five years ago. Many technologies support scripting languages to provide additional tools that cannot be provided by the host technology. Don’t be afraid to embed some groovy into your Java code if you need to. Don’t be afraid to use IPC to use a whole new technology alltogether for the new problem and its solution implementation. There is absolutely nothing wrong with using multiple technologies in the same system as long as two conditions remain constant. First, you are not adding more complexity or dependencies to your system. If so, maybe you started with the wrong choice of technologies to begin with, and it is time to start over. Two, the solution flexibility does not come at the expense of deliverability. At the end of the day, we are here to please the business. If the deployment of the new technology costs too much (learning curve, build scripts complexity, etc.) in terms of when the implementation of the solution will be available to the business user, then although it may look like it, but this is still not the right screw driver.

A great system is a hybrid system with many arms under its arsenal. The flexibility not only to change but adapt and play nice with new technologies is a powerful characteristic of great systems. So, try to select the “right” technology for the big business problem at step 0. Selecting the right technology means that you will be able to implement most of future solutions without having to change technologies alltogether or have to do “too much” to make your existing technology implement the solution as expected. Now, the system described above is a good system. What separates a good system from a great one is its ability to evolve and accept new technologies in its space without compromising the deliverability requirement. Just whatever you do, never use the wrong screw driver for the wrong screw. And as much as you hate Windows or Eclipse, there exists something out there that those two technologies or tools will marry perfectly into. So, don’t be a slave of technology.

It’s not working

February 4, 2010

There are a few things in life that I don’t like. They are so few that I couldn’t even remember them all now. But what I don’t like the most is when a developer tells me that the _____ (blank) doesn’t work. I will tell you exactly why I go bananas when this is th only thing I hear. When the code throws a white flag due to an unchecked runtime exception, blank doesn’t work. But blank doesn’t work either when  the computer does not start, or when power runs out. So, how the hell am I supposed to know what the problem is and how to fix it?

You know, I’ve had my share of “doesn’t works” from my users. Onetime, I was on the phone for over half an hour with an end user when the website was ” not working”. At the end, it turned out that he was looking at the website using Outlook (where all JavaScript was disabled from the view panel). Even with him telling me that he was 100% sure he was on Internet Explorer and still wasn’t able to see the menu options I was asking him about, I am still OK with that. What I am not OK with is when a developer wastes 1 minute of my time becaus she reported “it doesn’t work”.

Even for a QA, I wouldn’t mind hearing that from. As a matter of fact, I consistently tell my developers who complain about the QA not providing enough information to reproduce (and we all know how QAs and developers get along with each other), I tell them that when a QA doesn’t deliver enough information about a problem then it is the developer’s fault for not providing enough information about what is expected or providing enough logging for the QA to use and report more. I can live with a QA that dusts off all responsibility, and blow it my way through a “it doesn’t work” remark, but I sure cannot stand it when a developer says that to me.

There is a reason a language has millions of expressions and many overloaded words to describe events and happenings slightly differently from one another. Imagine all poems had the same word or sentence repeated over and over and over again. Oh wait, that’s most of our today’s music. But you get the point. “It doesn’t work”, is not a good description of what a problem is. This wastes time communicating back and forth to get more complete information. It also paves the way to sarcasm, which leads to disrespect and inflating politics. It further leads to, which is where those situations usually end up, being dangled in the middle of nowhere like a horribly coded unreachable else statement. That is how bad code builds on top of other bad code and problems.

Remember when I said there is nothing I don’t like more than a developer saying “it doesn’t work”? Well, I also want to tell you that I hate something else. And here I am using “hate” to describe (differently) how this is worse in my opinion than the thing that I don’t like the most which I talked about above. So, what’s worst than “it doesn’t work”? “it still doesn’t work”! Those statements sound the same right? Wrong! They sound as similar as Obama’s and Cheney’s hunting skills. I think Cheney is better at shooting his friends than Obama. When a developer comes back and says “it still doesn’t work”, from my experience, that means the new code with the fix produced the exact same error when the same scenario was run with all other influencing factors held constant and invariable. But, more often than not, it “also” means that I ran the new code with a different scenario and got the same error. Even worse, I ran the new code with a new scenario and got a new error. Yet, all testing scenarios described above were abstracted and encapsulated behind the same expression “it still doesn’t work”. When an end user or a QA says that, to me it means that the application is still not working. No matter the input or the scenario run. The end user or QA does not know all execution paths of the code from a low level perspective. They know a use case only. It is not their job to map a use case to an execution path in the code. That is the developer’s job. If you want more information from your QA, empower them with logging tools and knowledge. But be careful not to mix their responsibility as a QA with a developer’s responsibility to “debug” code.

So, the next time you want to report to me that the code doesn’t work, make sure you have already done some investigation and collected some information to share with me. Even if it is not your code, you should be smart enough to collect enough information to know where the problem is, and most importantly, know based on your debugging where to delegate the information to. I receive tickets for defects and bugs from end users and QAs, but I should receive “debugging information” from developers after they receive the bug from an end user or QA. Otherwise, if the developer is just passing around the bug as reported originally, or worse, as he discovers it on his system, then he will be as useful as another GPS in the same car.

Always debug the problem. Check out the logs. Try to reproduce. Collect more information from the user who reported the problem. Treat this bug as your bug until you cannot do anything anymore and have to delegate. And if a fix is pushed out and you countered a problem, try to see if it is really the same problem (under ALL isolated conditions) or a new one. Most technologies have great debugging tools and API as well as meaningful messages. And never say “it doesn’t work” or “it still doesn’t work” EVER again.