Creativity

Image may be NSFW.
Clik here to view.Creativity. I bet you don’t often hear people associating that word with programming – including programmers. Well, that is a big mistake. I don’t mean page/screen layout, color schemes, graphics, etc… While those things are very important to the overall success of a project they can be delegated to a graphic artist or someone who specializes in front-end design. What I am talking about is the creativity involved with coming up with the best solution to a problem. It is easy for a developer to do what the client wants – they come to you to make data import easier, for instance. The challenge comes in giving them what they need, as well as what they want.

What’s the difference, you ask? Well, suppose you go to the mechanic – you want an oil change but what you need is an oil change, new oil filter and a new oil pump. Do you want the mechanic to just do the oil change knowing you need the other stuff and will be back soon or tell you what you need and explain why? I would want him to give me what I need or at least present the options to me. I feel the same responsibility to my customer as a programmer.

Let me illustrate this with an example from a real-life situation. While working for a major technology company I was approached by someone in the Customer Service Department to assist them with an Excel spreadsheet (see Proactive Customer Service.) One of their managers had a small group of top-tier customer services techs on a special project. Each week the manager got a spreadsheet with hundreds of customers’ names and phone numbers – he then had to manually divide these names amongst the team and copy and paste the information into individual spreadsheets for the techs. They worked on the spreadsheets during the week then returned them to the manager who manually copied and pasted the data into a single spreadsheet to do reporting. This went on every week and took hours of productive time away from the manager. I was asked to write some code to do this process automatically. No brainer, right? I thought so at first but then I got to thinking. I sat with the client (in this case an internal client) and dug deeper into what the project was, what data they were collecting, how and what the expected end-result was. I then asked if they would like it to be web-based and their eyes lit up. The answer was “YES!” followed by “Can you do it?” and the rest, as they say, is history.

The first thing I did was create the spreadsheet solution so that they could have something right away. I then sat with the managers and supervisors to get requirements from them all and also compile a “pie in the sky” wish list of what they would like to have. I had enough information from this meeting to put together a quick prototype and demonstration. The managers were happy but wanted some changes, which was to be expected. The rest of the team was brought in to get input on the user end of the application. It turns out that the technicians had to access two (2) different systems to compile customer data before calling the customer to offer help with their problems. This created a lot of work, which took a lot of time. I ended up integrating the other systems into read-only sections of my app to give the user a one-stop tool. The application had an administrative section, a technician section and a reporting section, all with restricted access based upon the users’ Windows login. It was a huge undertaking because I not only had to build all of the front-end and logic, I had to build the SQL Server database on the back-end, handle access rights and build reporting functionality. The result? Everyone was happy and much more efficient. It helped the company deliver a better product to the customer which resulted in a happy customer. The comment below is an excerpt from a recommendation given to me by the project manager:

He worked with me on creating a customer satisfaction response platform for one of my projects and delivered a solution which was top class in terms of user experience and design and better than what best in class companies were already using at the time.

You can read the rest of this comment can be found on my LinkedIn profile

Now, it isn’t always easy to make the client see the value in what you propose or they may think it is too much for the first release. Your job is to explain that it is easier, and more cost-effective, to build the features now than it is to re-engineer the project once it has been put into production. This is something that many people overlook, including programmers. Adding a feature to an application – whether standalone or web-based – isn’t like adding an addition to your home. The new feature may require an extensive re-working of the underlying code and logic. If the client is still unconvinced it is your job to structure the application to minimize the additional features down the road. I have often done this throughout my career when I felt it was necessary. If I think a solution would benefit from some functionality that the client hasn’t asked for or claims they don’t need, I will try to make the code open-ended enough to easily accommodate the change later. This must be done within the time constraints of the job. I am not saying that you should always do things your way, in fact, the client is always right – you just need to show them the light sometimes. That being said, there are times when you have a very specific project with a project manager and strict guidelines that must be adhered to. In this case, you follow the guidelines and deliver the product.

The bottom line is that you can go through your career building what the client wants or you can go the extra distance and give them what they need. I think this is something that can be learned but it isn’t something that can be taught. It has to be developed through years of listening and observing.

Image may be NSFW.
Clik here to view.