Deceptive Software Products

Products to the naked eye look marvelous from the outside to the unsuspecting of us. I like to think of products (in particular software) as looking like this beautiful house:

Amazing isn't it? Beautifully laid out, marvelously sleek design, and inviting. The software may appear to have all qualities, but what about its foundation? Is it as solid and good looking as it appears?

Software users usually do not ask the latter and with good reason: They are abstracted from this because software professionals are suppose to ensure that the foundation is good. The problem is some IT managers and teams do not care about quality and are all about – “get it into production and forget the rest.” Do not get me wrong, I am all about pleasing the users and getting things into production as soon as possible, but when the number of hacks increase, and there are no unit tests or other testing methodologies in place to come back and confidently fix the hacks in the next release -- this leads to the eventual degradation of the product. Maintenance will become a nightmare, new features will sometimes have to be hacked in, developers will become afraid to change the code for cleanliness and maintainability purposes, and the broken windows theory will kick into full gear. This is a recipe for disaster in my eyes and will lead to developer dissatisfaction if proper measures are not in place.

When architects/engineers build bridges and houses, they pay close attention to detail and do not over or under promise things. In the software industry, we constantly see people offering the world and a cure for cancer to boot in the first or next version of its software. This in my opinion is part of the reason why at times software looks the way it does from the inside. For instance check this nasty Java hack:

public void foo(Object paramObject) {
...
...
 Object someObject = null;

 if (paramObject instanceof String)
 {
    if(“Y”.equalsIgnoreCase((String)paramObject)) 
       someObject = “Y”;
    else if (paramObject == null || “N”.equalsIgnoreCase((String)paramObject) ||         
             “”.equalsIgnoreCase((String)paramObject))
    {
       someObject = “N”;
    }

    //some other hacky hard-coded non-sense
 }
...
}

This one happens to be one of the most appalling Java hacks I have seen:

public interface SomeInterface {
  public boolean isConditionValid();
  public Results getResults();
}

public class SomeClass {
...

 public void foo(List<SomeInterface> list) {
  ...
  for (SomeInterface iface : list) {
   if ( iface instanceof ConcreteObjectA && iface.isConditionValid())
   {
      ConcreteObjectA a =  (ConcreteObjectA) iface;
      logger.debug(“A ConcreteObjectA is a part of the collection: ” + a.toString());
      doSomethingWithTheResults( a.getResults() );
   }
   else if(iface instanceof ConcreteObjectB && iface.isConditionValid())
   {
      ConcreteObjectB b = (ConcreteObjectB) iface;
      logger.debug(“A ConcreteObjectB is a part of the collection: ” + b.toString());
      doSomethingWithTheResults( b.getResults() );
   }
   //and more and more instanceof hacks below
  }
 }
}

This may not appear to be that bad for some but for me I find it deplorable. The same developer who wrote this, if left to his own devices, would destroy the product in no time with this kind of code. No understanding of polymorphism, object hierarchies, or design; really no understanding of anything other than javac and java commands. This individual is making a six figure salary writing this kind of garbage! Excuse my indignation but it upsets me that this same developer would go out of his way to bash software development and proclaim that is merely all just another if statement. Yes, it may appear to be easy on the surface, but proper design and coding techniques are rewarding, hard work, and part art - part science. These samples represent the worst in coding style and design, and are the reason software systems have shady/fragile foundations. I may submit the code to CodingHorror.com and also write a book called “101 coding hacks I have seen” or “Hacks r us”.

I know better when I see the product built with code like this and see it from the foundation upwards this way:

Time to put on the hard hat and get to work!

Follow me on Twitter mrosario2012

And furthermore, my son, be admonished; of making many books there is no end; and much study is weariness of the flesh. Bible- Ecclesiastes 12:12

Do you want to get something going but feel like you need lots of expertise to do so? Feeling this way, you buy books to learn things that will help you achieve your goal because you believe some level of knowledge is needed. For the time being this does not seem like a problem. However, you then begin to search online to see what the gurus are saying, and they are saying that more is required. You begin to think that what you have done is not enough so you then decide to stock up on more and more books. Then you begin to realize that your time is limited and now you decide that you need to learn about time management and spend more time looking for gurus and books to help with this dilemma. And on and on and on goes this never ending quest for perfection and well-roundedness.

As you can see from where this is going, you can continually find areas that you are not an expert in that can easily derail and push you towards seeking more advice from experts. The problem is you will never be an expert in everything so just learn enough and get started! Version 1 of whatever you are building or trying to do does not have to be perfect! As a matter of fact it will never be perfect so forget it and get started. If you keep trying to learn it all when will you actually embark on the journey to get something done?

Look at craigslist.com (some would argue that the look and feel is still version 1)... It is a multi-million dollar business built on simple principles. Craig Newmark did not waste his time trying to figure out HTML, Javascript, CSS, and web design in depth by buying an endless amount of books, going to seminars, or reading endless articles from experts. He just was passionate about an idea, built it out, and let the people decide where the product needed to go. Imagine if he had tried to be a jack of all trades and would have attempted to learn everything about server and client side development; craigslist.com would have taken much longer to launch or may have never launched at all if he would have gotten a bit discouraged learning any of the necessary components. Sometimes it is just good enough to know enough to accomplish a task. Let's take a web development example.

Say you decide to build a site selling shirts on your own (you should probably have a partner but building it on your own is fine). You will need to know HTML at a minimum and some server side language like PHP, Python, Java, Perl or one of the many others. So how do you start? Learn enough to cover what is needed to get the product out and refine it over time. You do not need to be an expert in any of these areas to get a product out, just need to know enough to make it live and improve it over time. I have a friend that has no formal background in Computer Science or programming whatsoever and decided to make a social website for people to find information on parties and concerts (targeting the Latino market). He wanted to learn PHP and HTML/CSS/Javascript so he set out to build this site which he did and improved it over time. In a few years time, the site was grossing a few thousand a month, was elegant, and he ended up selling it for a nice six figure price (will try to post his story, name, and the site in the future if he permits it). Not so bad for a novice that learned something new and became passionate about it. He told some of my friends that he was learning as he went along and did not let his lack of knowledge discourage him or set him out on a expertise expedition. He learned what he needed to know to get enough done today, then learned the rest as he went along. This point is expressed pretty well by our friends at 37Signals in this blog.

Imagine if you needed to be an expert to be in shape? The gyms would be empty and lots more people would be overweight. “I need to learn the chest chisel pump from so and so in order to build my chest so I will delay the gym until I learn from this expert”  This is silly non-sense. People often go to the gym with some basic understanding of what they have to do and learn as they go BY DOING. Sure they may have a trainer but they are still engaged in the act of DOING NOT READING. If you really need expertise in a certain area, hire someone who knows that area well so that the product or task you are trying to accomplish does not suffer a long delay. This is introduces parallelism into your life allowing more to be done faster (remember life is short). In this example hiring a trainer to work with you as you actually do the exercises is a good example of this parallelism – you are working out and getting expert advice at the same time as opposed to reading tons of books and magazines then working out (if you ever get to it). Tasks that are not dependent on each other should be done simultaneously to expedite the process when possible.

Reading and more reading can be a form of procrastination and can lead to anxiety. The less you do because of the less you think you know will probably result in thinking you are not capable of achieving. This will lead to getting-it-done-paralysis. Another problem that may arise is that suddenly after reading all the books and listening to all the gurus, you feel overwhelmed and are now definitely convinced that you do not have what it takes both consciously and subconsciously. This may lead to some common forms of procrastination and busy work like “finding that your place needs cleaning”, “you need to relax more after work and you do not have much time to get it done” (funny enough though you have time for the idiot box, i.e. TV), you will “start next week” or “over the weekend”, and on and on and on.

Now obviously I am not promoting this as a scientific journal but I am talking from my own personal experience and from what I have read on the web. Stop reading so much and get out and do something. Life is too short to try and become an expert at everything. Learn enough, do it, and improve it as time goes on. If you get nothing from this blog post get this! Do not worry about not being an expert now, the experts were novices at some point too but they started and overtime they got there. Make it happen and stop reading/listening and seeing others achieve – achieve yourself. Do not become someone else's cheerleader, live you life and do what you must – achieve!

Follow me on twitter mrosario2012

Hello World on Steroids: Are You Building Lego Applications Today?

In the era of the almighty frameworks and reusable APIs, we are now in a position where applications can be put together quickly. This is awesome for people bootstrapping companies or anyone in general who needs to get a functional application up soon. My question and fear is what does it do to our understanding of the core elements of the system? Sure, we can run to the documentation or get a patch if one of the application layers beneath ours breaks, but wouldn't it be good to understand how things worked to some detail?

Welcome to the world of “Hello World on Steroids.” The era in which some programmers have become systems integrators and are merely just moving data: Read from a queue, do some simple data manipulation, write to the database, then write to a reply queue and repeat this pattern for all other applications. Not to knock systems integrators (systems communicating is necessary), but if this is all your doing, you may be effectively losing the ability to write algorithms and solve problems (I speak partially for myself here as I was experiencing this for awhile and still am to some degree; I know a lot of you out there are in the same boat.) The frameworks and APIs available are powerful and all encompassing, take Apache CXF for instance. This is a pretty powerful framework offering a lot out of the box:

1. Multi-transport support: HTTP, JMS, TCP/IP, etc
2. Various protocols support: SOAP, RESTful messaging, XML, CORBA, JSON, WSDL, etc

Apache CXF has a lot more features than this but with this short list you can kind of get a feel for some of the capabilities it possesses. This framework alone does not rob anyone of problem solving ability but the APIs that come with the core Java language and all the free stuff out there may. You will probably be writing nothing more than POJOs with getter and setters wrapping the real APIs doing all the heavy-lifting. Want to connect to the database reliably and manage connection pools? Use Spring and Apache DBCP. Want to serialize an object to XML and deserialize XML to an object? Use JAXB. Want to create a tree structure or hash for some data structure you are creating? Use Java's Collections framework. If you are in an organization that has a lot of stuff built in-house that you have to use, the same applies to you – most of the work done for us out of the box. All we have to do now is design and put things together like Lego blocks. Therefore, the hard thinking is done for us by a generous bunch of geeks. So are we becoming mere dot-getters and dot-setters?

These frameworks and APIs are great or so you may think, and I agree at some levels, but how does this stuff work? How do you use it properly if you do not understand or cannot write one yourself? What happens if it breaks in production? Do you stare at the stack trace in fear and run to the closest browser for your coding ally and team-mate Google? This is a dangerous position to be in as a developer and effectively dumbs us down over time if we are not doing anything challenging. Some of you may be saying: “Ok I get what your saying, but this stuff is open source and I can see and learn from the code, isn't that enough? Documentation for a lot of these tools rock as well so I do not need to know anything at all. Also buddy, the web community out there is supportive and someone will have the answer on Stack Overflow or some other site no?” First question: It may well be enough but I contend that a lot people may shy away from getting the source and learning from it. To the second question: these communities are awesome and a God-send; yes we cannot know everything and it is more productive to ask instead of wasting time thinking about what went wrong but if you do not think at all your in for serious trouble in the long run.

Fundamentals should be covered in detail and well understood. Whether it is covering these things extensively in college or on your own, you should know at least how data structures work. As a developer, you should have some core knowledge of algorithms and framework development to begin to understand what may have been the design decisions of the team building the frameworks you use, the choices they may have made while building it, how they may have built it, advantages and disadvantages the framework may have, and this may be the best part: potentially extending it and/or contributing to it. If you are contributing to a framework and/or API this is a good sign that you are on the right track and probably passionate about the field. This to me is also a sign that you may possess adequate knowledge in the area. If this is the case for you, then this article is a moot point to gloss over and ignore. For the others out there who are not in this subset and belong to the dot-getters and dot-setters club be warned: Go beyond just putting applications together as Lego blocks and try to get some depth in some area.

To end this I would like to say, I strongly agree and support the notion of Lego application building and reuse as much and as often as possible. There is no point in reinventing the wheel over and over again when problems have been solved efficiently by people with expertise in niche areas of the field. My problem is when developers make no effort to understand the plumbings of what it is they will be using and are just happy making API calls to get the work done. I think this is a dangerous approach to take and just waters-down what we do for a living and takes some of the greatness out of it.

Follow me on Twitter mrosario2012

Do you have any questions for us?

This age old question is usually asked in a disingenuous way at the end of interviews and is rarely viewed as an opportunity by applicants to ask questions (for good reasons most of the time of course, i.e. we are in a recession so we can't be too picky). Despite external conditions, I think it is high time people started asking some questions at least to get a sense of what they are getting into. I for one should have asked some intelligently worded questions to get a hint of the nightmare I was walking into; sure I am making more money and we are in a recession, but the place is Chernobyl. At times it feels like interviewers are not that sharp and are just Googling for the hardest questions they can find to ask someone; questions they could not answer themselves without looking up. Had I known what I know now, I would have tried my best to make amends with my previous employer or at least attempted to move across IT departments. Oh how I languish in this dysfunctional organization...

Anyway, enough of my ranting... what should we or could we ask without seeming like an antagonist before accepting the offer? I can only write about programmers (from here on referred to as IT) in this particular blog because that is what I do but can and will add questions others submit for other career paths. Before we answer the questions just raised, let's talk about some of the things you can do prior to interviewing:

1. Find out about the company culture from insiders and people that have worked there
2. Find out how integral a part of the company the role you are pursing will play
3. Find out how much the company invests in IT and where they stand in terms of reputation and ability
4. Find out how often they hire and what is the turnover rate
5. Is it a sweatshop?
6. Find out where they recruit talent (not too important and can be misleading but you should know)

These are just some of the many questions you can start thinking about before even walking in for an interview. Remember, if hired, you will be working with these people for the minimum of 8 hours a day and will absorb some aspects of the culture, good and bad, and will be working with the tools that are in house to get the day to day done. So, lets dive in to the six preliminary things to explore before approaching a company for employment.

Number 1: Find out about the company culture from insiders and people that have worked there

This can help point you to the potential good and bad qualities the company embodies. From investigating the culture, you may see a few things:

1. You can see what kind of internal politics may exist
2. It can also tell you whether there is a decent hacker culture (good hackers, i.e. good programmers/architects/designers)

This in no way is a silver bullet, but at the minimum you are doing your due diligence to determine whether it is a fit for you. If you have friends there that are happy and not leaving anytime soon, you may choose to not look too deeply into this. Working with friends is a cool thing and helps productivity.

Number 2: Find out how integral a part of the company the role you are pursing will play

This is important depending on what it is you plan on getting out of the job. If you are taking on this new role for more family time, time for school at night, more time for side work, or building a company on the side as our friends from 37signals suggest, then what you may be looking for is a role that is not too time consuming and intense. Do not step into an area where you will be building the equivalent of a rocket ship if you have outside interests you wish to pursue. You will hate yourself if you do.

However if the focus is to get into full-fledged career mode, and you are looking to grow in a new and exciting company, then you should be looking for a role in an area that will have a decent if not great impact on the organization. This should be in an area where you can flex your intellectual muscle and contribute to the bottom line in a way that is satisfying to you, the customers, the team, and the company. You will be looking to try new things, learn new technologies, new algorithms/methods, and work with a happy bunch of guys who just like doing cool stuff. This is the nirvana state; this is where we all want to end up whether it is working for ourselves or someone else. This is what I seek at the moment.

Number 3: Find out how much the company invests in IT and where they stand in terms of reputation and ability

The reason I mentioned this one is because of my current plight. I left an organization that placed a high value on its IT staff, despite IT being viewed as an expense and not a core part of the business. The end result of placing high value in IT was that they got more out of IT. This enabled them to build cutting edge platforms and frameworks that gave them an advantage. This technology was standardized within the company so all groups were able to use it, and it had great support and documentation. Applications were built quickly and easily in-house. Drawbacks to this of course are that the IT guys not building the frameworks and tool sets became highly specialized and are completely absorbed by all the in-house stuff. They can potentially lose touch with the open-source frameworks and tool kits over time. A win-win for the business, yet questionable for IT. One can argue that you can keep up with open source when you get out of work but I would argue that most people do not.

Coming back to my point, a company who just views IT as some sort of a utility or tool to use and does not invest or place value in that section of the company is bound to have the following symptoms:

1. High turnover rate (bad for business and the product)
2. Bring in bad developers, i.e. political scientists (those damn politically inclined employees!) masquerading as computer scientists
3. Turnout buggy software and bad practices (this will ruin you in interviews as this infectious disease will take hold of you)
4. Be very tactical and not strategic (not such a bad thing all the time as we cannot predict the future and should build for today's requirements; they call it software for a reason: it is flexible and can be refactored)
5. Have a shitty vision and leadership

I had one Managing Director (MD) tell me that IT is viewed in most places a light bill, something you hate to pay but need to. These kind of statements are detestable to say the least. This sort of overt minimization demoralizes hard working smart people and leads to 1, 2 , and 3 above. Programming is very creative, dynamic, and fluid to say the least. It is very rewarding when you can take an idea and materialize it in the form of software. I think that this is exciting and is what drives me.

Number 4: Find out how often they hire and what is the turnover rate

If people are leaving all the time you need to know this. People leaving in droves from a company may be a sign of some nasty things taking place that people are running from. You may be walking into a land mine field. Please if you take none of my other advise at least consider this one. We all deserve to be in a decent place of employment.

Number 5: Is it a sweatshop?

If the culture is about ASAP, get it done now, we work around-the-clock crap, stay the hell away if you want any semblance of a life! If you like working in this way, all power to you but remember the company will probably forget this when it comes time to hand out the pink slips. In the words of the rapper Pharell: “You should think about it, take a second...”

Number 6: Find out where they recruit talent

Where they recruit talent tells you a few things:

1. It tells you the caliber of people that you will be working with
2. Allows you to investigate the kinds of people you will be working with indirectly by understanding the campus culture they can from (you can find out about the school culture through social networks and online resources). We are all, at the end of the day, the sum total of our experiences and products of our environment
3. What kind of leadership will be emerging from the company in the years to come as these developers mature and grow. Please note though, that if the culture test fails because of extreme politics, it is likely that this talented pool of employees will either become highly political themselves or just leave and go somewhere else. True hackers hate politics and just want to work with good people having fun solving problems together and cutting cool code

Please take points like the last one with a grain of salt. Some people that go to Ivy league schools are not as great as their resume makes them appear. I worked with a few individuals from Ivy league schools that were shockingly bad and did not understand the fundamentals of comp sci. Also, the non-ivy leaguers tend to work hard because they are at a disadvantage from a recruitment perspective. They know their schools will not likely open any doors. They tend to work really hard to learn and are usually passionate about what they are doing. In the end though, it is hard to really rank people until you have worked with them and seen their output.

Questions to ask interviews/employers

So what questions should we ask after the interview? Here is a short list of questions we can ask (open to suggestion, these questions are just what I have thought of pretty sure you guys have better ones):

1. What kind of source control systems do you use? You may think everybody is using this these days but you will be surprised. I know of a friend in Wall Street who works with a team that has special folders where custom scripts check timestamps for “check-ins” and promote code to production. They do not use source control at all. This is madness!
2. How big is the team and how much are you planning to grow to? Is this a new team? (If it is not a new team and they are growing fast this can be a sign of people having quit in the past or were laid off or may just be a genuine sign of growth)
3. What kind of work is the team doing now and what will the new team member be working on?
4. What level of support does the team provide? Level 1, 2, or 3 or all?
5. What technologies are you using currently and what will you be using in the future?
6. How is the team structured? Do you have a technical lead? Are your projects tactical in nature or strategic? If tactical, will the focus ever change to strategic? (if all they are doing is tactical work, then you may be going in to a maintenance shop where real development may not be taking place and you are just bolting on new features or fixing bugs; but as Guido van Rossum points out code is often read more than written so it will probably be hard to get into fresh development but make sure you are comfortable with this. Code maintenance and development ratios should be balanced wherever you go)
7. Do you have code reviews? Architecture reviews? (Signs of how much they value quality and strive to keep things clean; again within reason not incessantly everyday in the form of micro-management)
8. What kind of work is coming down soon?
9. Do you have a QA team?
10. Do you have an automated build process in place?
11. What are your release cycles?
12. Do you split the team up between UI and server-side developers?
13. Do you have an Business Analyst for requirements gathering or is your core development team in charge of this?

There are many more questions one can ask to try and understand what they are to expect before taking the job. You will not be asking all the questions but should select from the sample above and whatever the community submits and judge which ones make the most sense in your particular situation.


Follow me on Twitter mrosario2012