I don’t code often these days; but when I do…

I don’t code often these days; but when I do… good things happen. A few months ago, I came across a tech challenge sponsored by Vistaprint (now Cimpress). The challenge was to identify the most efficient shipping box given a set of objects of various sizes. When I accidentally came across the challenge, I really felt I could win. So, I started to plan out the algorithm and started coding with whatever time I got on a daily basis.

Despite having limited time, I was really glad to have completed the task on time. Then I had to wait about a month to know the outcome after I submitted my code to Vistaprint. What was the outcome? No, I didn’t win. Congratulations to Lars Szuwalski from Denmark for winning the competition. But I certainly was happy to find out that I got honorable mention along with 3 other folks. Congrats to them as well.

Here’s the link http://lifeinvistaprint.com/technology/vistaprint-tech-challenge-winner-2014/. You can read about it.

Software Architecture – Trust Your Instincts

Are you a software developer or an architect? Do you enjoy working on cool projects? How much time do you spend searching through the internet when you are stuck with something, or trying to come up with creative solutions? We often rely heavily on expert opinions of many thought leaders – hoping that they have been there and done that. We try to read many blogs, articles and books. We also look for sample codes to gain insight on areas that we are not familiar with.

I am no different. I have done it in the past, and I continue to do it. However, every now and then, I hit that architectural impediment - a problem either not encountered by anyone or the solutions provided by the experts are simply not appropriate for me. Blogs, articles or books go out the window. What do I end up doing whenever I reach such an impasse? Look deep inside and start trusting my instincts; block out the internet and start scribbling on papers. Soon enough – a state of epiphany emerges, and out comes an architectural design that I am happy with.

I am sure many of you have had similar experiences. If not just trust your instincts and you will observe what you are capable of.

Technical Documents - Express More with Less

It is not uncommon for systems analysts, software developers and architects to produce series of documentation during all the phases of software development life cycle. We call these documents by many names. Business Requirement Document (BRD), System Requirements Specification (SRS), Functional Requirements Specification (FRS), System Design Documents (SDD) and Technical Design Document (TDD) are some examples. Many people and organization call these documents by various names; but they more or less serve the same purpose.

VehicareCentral launched in Beta Mode

VehicareCentral is now in beta mode since 01/02/2012. Please test drive for free, and it will remain a free site.

XML Transformation - Use XSD please...

Whenever organizations share data in XML format they may end up taking the following steps to process the data:

1)      Transform XML to an internal standard

2)      Process the transformed data

Please note that the data sharing strategies, processes and complexity can vary significantly from one organization to another. Therefore, the steps outlined above may not cover all scenarios. Here, I’m just trying to highlight a simple XML driven data exchange scenario.

Rigid vs Flexible SDLC

Most organizations follow some type of methodology for their software development life cycle (SDLC). Waterfall, Agile, Scrum, Lean and XP are some of the principals many corporations are trying to utilize to effectively build software products. There are definitely no shortages of books on these methodologies, and the number of great blogs is countless.  I certainly don’t want to try to publish one more blog on promoting a specific software development principal, or discuss the pros and cons. Instead, I feel I need to look at why an organization establishes SDLC to begin with, and what type of methodology we should try to use.

App Law?

Most organizations use some type of home-grown application for one reason or the other. These applications can be as simple as a single user Excel spreadsheet or as complex as interdependent line-of-business software products servicing 100s of users. All these applications, regardless of their complexity (or simplicity), usually run their courses… Sometimes we end up spending a great deal of money to replace the product only to find ourselves in the same situation within a short period of time.