If I were to ask a non computer scientist to design a program to sort a large list of numbers [e.g. 43, 2, 10, 7, 87, 0, ...], they would probably design a program that resembles sorting a deck of cards, like this; pick up the first number in the list, place it in a new list, pick up the next number in the original list, place it in the correct order in the new list, and so on, until all the numbers in the original list were placed in the new sorted list. They probably would not come up with a scheme that randomly selects an element in the list with which to partition the list in two, moves all the elements that are smaller than the "pivot" element to the left of the pivot element and moves all elements that are larger to the right of the pivot element. And then does the same partition and move operation to the left sub-list and the right sub-list on and on until the whole list is sorted.

The former method has been coined in computer science as the Insertion Sort and is one of the simplest sorting algorithms in existence. The later method is known as Quicksort and is one of the more complex sorting algorithms but it has better performance for very large lists. Early computing was very concerned with sorting, therefore many came up with creative solutions to the problem of how to sort lists faster.

Programming is about problem solving, e.g. how do you search through the internet for a particular term, how do you automate the process of signing up for health insurance, how do cost-effectively handle seasonal and/or random spikes in demand for a particular piece of content on the internet, etc. When attempting to solve these or any types of problems, the best programmers are the ones that can think outside the box. You often have to get creative and/or inventive. Conventional thinking in problem solving scenarios often does not cut it as you are boxed in by those conventions.

I recently worked on a project in which a very intelligent co-worker came up with a scheme to use IBM Websphere Message Broker, which is a tool for enabling communication and transformation of data between heterogeneous systems, as a simple web server in order to avoid having to spin up a web application project. This got me to thinking; how does an up and coming developer go about in increasing their creativity in problem solving? Here are some of my thoughts in that area:

1.  Understand what a component / tool / library / technology does, how it works and what its properties are. Not just how it is used or how to use it. Regular developers understand the latter, great developers understand the latter. For example a regular developer may know how to use an XML parser, but a great developer may have a deeper understanding of how it works and use that knowledge to re-purpose it or use its underlying concept in another project

2.  Question assumptions / question everything. Ok maybe not everything, but ask more questions and certainly question assumptions. Some may hold up and others may fail. Still, you dared to challenge the status quo and that could pay dividends.

3.  Allow yourself to dream. Don't dismiss thoughts or ideas early in the process. E.g. "what if we could have a natural sounding conversation with a personal assistant or other apps on our phones", "what if I can incrementally push the results of a query to the client instead of having them pull it".

4.  Build on others ideas. The best ideas aren't always original, neither are they always revolutionary. They may be evolutionary. You can even combine two or more ideas into one.

5.  Test out little ideas. Build little prototypes; these will help you fully process the idea, encourage you to continue with a good idea or to dump / refine a not so good idea, and help you gain traction if you have to sell your idea to someone else.

6.  Don't be afraid to fail. This one needs no explanation.

This is by no means an exhaustive list, just a couple to get started. Here are some general thoughts on creative thinking skills from palgrave.com. Thanks for reading!

Exception handling is one of the basic things a programmer must know. Bad things happen during the execution of a program; a file cannot be accessed, a user enters a value that's out of bounds, the program runs out of memory, etc. Exception handling provides a means of responding to those "exceptional" conditions by switching the flow of execution of the program to a specialized block of code which contains instructions to respond to the occurrence of the exception. In addition to switching program flow, languages and execution environments that support exception handling typically provide an exception object that provides information on the exception that occurred and the state of the program when it occurred.

Over my years as a developer, I've learnt a thing or two concerning exception handling that I thought it would be useful to share.

One such lesson concerns when to throw an exception. I have seen exceptions thrown in situations where a variable is not set by a user or a SELECT database query returns no rows. I would argue that, in general, exceptions should only be thrown for faults that are either truly exceptional conditions or that are outside your control as a programmer. If a form requires certain fields to be filled by a user, don't let the user submit the form without filling the required fields. If the form fields specify certain data types, be sure to validate the input before processing. If a database call returns an empty result set, your program should in turn return an empty result object (not "null", if you can help it) to the caller. In general, exceptions should be thrown only when truly needed because it alters the caller's execution flow.

Another lesson is where to put your exception handling code (catch block). In general, you should not catch exceptions that they can't respond to or handle in some way. Instead, let the exception bubble up to the appropriate class or method that can handle it. Eventually, all exceptions that can be caught should be, unless you think having your application crash unexpectedly is a good idea. However, the catching class / method should be able to do something about the exception. There are a some situations where you may want to catch an exception, perform an action, such as perform some cleanup or do some logging, and then throw the exception up the chain. You should employ this strategy carefully though because in most languages you lose the stack trace that shows the actual origin of the exception i.e. the stack trace would show that the exception originated from your throw statement, instead of the original location.

When you do catch exceptions, you should always try to recover gracefully and logically. For example, if a database connection is unavailable, you may wait for a couple milliseconds and try again up to two additional times. When recovery is not possible though, the exception needs to be reported to the user with as much detail as the user needs to respond. An exception message that says "Could not open file because it was locked by another user" is better than an exception message that simply says "IO/file exception". For applications with human users, you need to know your users and tailor your error messages accordingly. Developer users are more savvy than business users and can handle more complex messages. Error messages targeted at business users or a general audience should use simple language to state what went wrong and what the user should do in response (e.g. try again in a couple of minutes, contact technical support, enter correct data, etc.). You can always provide a "More details" button with a stack trace or description of the machine / application state if needed, for debugging purposes.

Finally, for debugging purposes consider writing logs and giving users the ability to set the log level. This way, when an issue occurs, savvy users can increase the log level and send you the logs or do their own investigation. Also consider error reporting systems, like the one used by Firefox, that can either automatically or with the permission of the user send an error report back to you.

Thanks for reading!

I'm reading "The Passionate Programmer" by Chad Fowler and one of the chapters in the book talks about standing out as a top performer at work by identifying pain points that your development team puts up with on a daily basis and making a plan to fix them.

As I've learnt, knowledge that's not put into practice is useless / unprofitable, so I examined the challenges and pain points that we face as a development team at the organization that I work for and one of the pain points I identified in my current role as a Websphere Message Broker developer is with the deployment mechanism.

Broker Archive (BAR) files are used to package code artifacts that were created by a WMB developer for deployment on a WMB Server. In addition to being a container for code artifacts, WMB also lets you override properties defined in the WMB code artifacts by specifying these overrides on configuration files contained in the BAR file. This scheme is great because it allows a developer deploy the same code artifacts to different environments, e.g. DEV, TEST, PROD without having to change the actual code. Configurable properties such as the database connections, log file location, queue names, etc., which may be different between the environments can be specified on the deployable artifact (BAR file) instead.

The issues our team has with the BAR deployment mechanism is with the tooling for it. The Websphere Message Broker Toolkit, which is Eclipse based, organizes all the configurable properties in a non-intuitive tree structure, which in combination with the sheer number of properties in a small WMB application, makes it very easy to miss setting a property. The result of this is that we have had several times when a WMB application gets deployed to production but has a property that the deployer missed that points to a test queue, datasource or log file. This can result in us having to back out that deployment or worse, not noticing it until there is an adverse effect in the production environment.

My solution to this problem was to create a tool which would interrogate a BAR file for all its relevant configurable properties and display them in a simple table structure. In addition, the tool would highlight properties that don't match what is expected for a particular environment. For example, if a BAR file is destined for a production server but has a property that points to a dev or test web service endpoint, that property would be highlighted. This makes it extremely easy for a deployer to spot a misconfigured property and take corrective actions.

In thinking of the best delivery vessel for this tool/service I decided an Eclipse plugin would be the best vessel. Since I'd never written an Eclipse plugin before, I had to learn how to write one. In my odd little sense of humor, I call my plugin BAR-Tab, with the tag line "keeping tabs on your BAR files" :). The beauty of this solution is that the plugin can easily be deployed to the Message Broker Toolkit and be used in concert with the standard Broker Archive Editor. Here are screenshots of BAR-tab compared with the default tooling.






This is only version 0.9 of BAR-tab, therefore at this time it is read only and it doesn't have any pretty icons. Leave a comment or contact me if you want more details.