New Year, New Look – Technology

Technology – is quite literally our bread & butter.

Our strength is .Net (& associated technologies) & NodeJS (& associated technologies). We work on everything from desktops, web, mobile, hybrid & cloud. We develop for custom line-of-business applications, one-off mobile apps, API’s, Arduino-based robots and everything else that is possible within these technologies. We work with databases like SQL Server, MySQL, Oracle, MongoDB, & CouchDB. We are decent with SSRS, SSIS technologies. We work with Azure, AWS, Heroku & AppFog cloud services. We have worked on various domains like Banking, Insurance, Mortgage, Media & Healthcare.

It is easy to go crazy & get the best-in-breed for what we need as our IT stack (both in-house + client-facing). However, we believe that we need to keep our in-house technology costs to a minimum to free up more capital on other revenue-generating areas like: Client Projects, R&D, Sales, Marketing etc., given that we are self-funded (aka: its coming out of our own pockets!)

So, while we can (& do!) use all of these technologies & tools – we prefer to keep our own internal systems as light as possible by using Open Source Software, where possible. So, Notepad++, Visual Studio Express Editions etc., are more common place than full-blown Premium Editions for anything internal. Thank you OSS & the people who contribute their time/effort to creating them – our small company is totally dependent & grateful to the community. On our future to-do list – we have a goal to contribute back sufficiently to the community & hopefully show our respect to the whole initiative.

On the other hand, client-facing projects & R&D get all the love – best of what we have today, with a healthy does of “is there an OSS option” before we plunge into licensing & installs etc.

To help focus where we really want to spend our limited cash, we came up with a simple criteria as below:

  • Client-facing IT
    • Will do whatever it takes to deliver the best results
    • Costs are offset via pricing of that specific service
  • R&D efforts IT
    • Will take a one-time hit on specific projects
    • Will be OSS, where-ever feasible & if we have alternatives to a specific technology/solution
    • Costs are budgeted for the year & spend is monitored
    • Expected ROI is tracked very closely
  • Internal IT & Website(s)
    • Will be OSS, where-ever feasible
    • Each item given a nominal value of $50/year (or less!)
    • The only spend allowed for items in this bucket are related to security & privacy of data, which might push up the nominal value

The Cost of a Website

With our limited budget of $50.00/year (or less!), here is our technology stack & costing for this website:

Description Cost

NodeJS with Express Webserver. Front-end is built using Bootstrap with Font-awesome & a sprinkling of custom CSS. All code done using NotePad++  as IDE, keeps the overall tool licensing to a minimum!

Source Control & Issue Tracker

BitBucket has been our go-to system for both source control & internal issue tracking. Couple of reasons for this selection: unlimited PRIVATE repositories (a must) which GitHub does not provide! Built-in Issue Tracker (not the greatest), however it can be independently private and/or public to accept bugs. Limits to 5 users – which is effectively more than double our current staff. What else can a SMB ask for?


Mandrill/Mailchimp for email/campaign  solution (12,000 emails/month free rocks!) & we don’t blast out half that. AWS SES is another option, but we wanted a higher-level of functionality (like: Campaigns, Mailing lists etc.) without having to write & so Mailchimp it is.


all images assets (& eventually all static files like: .css, .js, .html etc.) hosted by Cloudinary Free account. 75,000 images in that band & we have uploaded 21 of which 15 background images of the home page & remaining various versions of the Logo, Favicon & touch-enabled versions for iPhone/Andriod/Windows.


AWS Free-tier for 1 year rocks! (& keeps the $ down too). Node-clustered t1.micro Ubuntu instance deployed to US-East data center. We don’t have large traffic (per our Google Analytics Stats). But if we see loads moving up, we will scale. A Load Balancer + 2x t1.small instance would suffice for the next step if/when we get to it.

*AWS Free-tier year 1;
Domain Hosting

GoDaddy (irrespective of their racy ads, which we love in a quirky way!).

*$50.85/5 years (1 year free + 4 years of hosting)

WordPress free edition to host this blog site & all the goodness associated with it! Yes it is not branded site & neither is it subdomain-ed under However we are pulling latest 3 entries from the blog into this site & based on how the traffic goes we will plan for better integration. We do have an up-coming release to have to point to this Wordpress blog

 Total Cost (year 1) $20.17

NOTE 1: we don’t have a SSL Certificate for this site. We will need one eventually, especially one that covers sub-domains like * If anyone has a good (& cheap) option, drop us a note.

NOTE 2: read the above cost breakdown purely from a website running perspective. We have not added the legal documentation costs of running a start-up, into this list as it is a different bucket of expense to the whole IT-side of the business. Perhaps one day, we might put that up into a blog post too.


While keeping the costs lean is ideal, we want to be practical & do what is absolutely needed & cut out the rest. Do you see anything that can be changed and/or needed which is missing from the list above? Leave us a comment.

Read the Series:


New Year, New Look – Design

Here is an interesting quote, which highlights our design philosophy:

Without good design, it is easy to miss the point
– Bjarni Wark

As a small start-up company, our need to project the branding/messaging is key both as a means to show the differentiating value we bring to our clients & as a message which will resonate with them if they had an opportunity to just glance over it once.

After a lot of debate, the simplest mission statement we could craft is:

We Deliver High Quality Software
– IT.Wox Mission Statement

This statement captures our area of work (namely Software Development), our approach (of Delivery) & what the client can expect in the whole process (High Quality).

Needless to say – our whole design now revolves around this message.

The Offerings

Limited as our team is, we cannot (& will not!) promise to do everything under the sun. Rather our focus is simple & plays to our strengths:

  • Consulting: which applies to one-off point-in-time help to our client needs for Architecture, Design & Development of Applications (usually web/mobile or hybrids). We bring over 20+ years of experience in this space & can help guide our clients for simplest to complex enterprise-grade implementations.
  • Development: which applies to our own development efforts, be it Open Source Software or custom Software Products (to be announced soon!) and/or custom development for our clients. We are hands-on technical team with skills in .Net & NodeJS platforms.

Our belief is that a company is successful if it has both Consulting & Development offerings. On one hand, Consulting exposes you to different & unique experiences with a constant need to quickly assess situations & provide solutions within a pre-defined timelines based off your past experiences/knowledge. On the other hand, in-house Development gives us the technical depth to dig deep & have our own arsenal of tools & techniques to offer when our clients approach us with their specific needs.

The Design

We feel our new site captures the mission statement & our current offerings really well.


Our mission statement really pops out with our service offerings following with clear Call-To-Action buttons inviting the visitor to contact us.

The site is responsive. We are using the excellent Bootstrap CSS framework for the responsive behavior & alignment of various components. JADE view engine delivers the HTML over ExpressJS web-server. We did think about Angular/React/Flux/(you name it…), but at this point we kept the over-all development complexity to a minimum by sticking to plain-old HTML renderings.

While the page content was intentionally kept spartan to avoid information overload, this layout allows us to expand the number of widgets on the UI & gives us an ability to show-case various items in the future in a dashboard-y way.


One important addition to the UI is the Contact Widget:


This widget will be visible on most of the screens in the new design, albeit with few modifications of the title to make sense in the different page contexts like so:

Capture2 Capture3

This allows our visitors to reach out via email and/or via our Twitter account for any question and/or comments in a consistent manner. Over a period of time, we hope to add a LinkedIn, Facebook & Chat/IRC links here.

While having an email contact for support is no-brainer, we did debate including the Twitter account up there. We look at Twitter as a social communication “headliner” rather than a discussion forum. However it might help promote the brand by having few tweets going out at the current stage. Time & experience will give us better understanding of this design decision.


Blogging is going to be key for us to show-case some of the interesting happenings around IT.Wox. Besides the title of our Blog is pretty cool (IMO):


Needless to say, it had to be part of our home page.

We currently pull in the 3 latest postings from our blog & show up on the UI.

Ideally we would have liked to pull in content based off a specific tag and/or set of tags (e.g.: pull content which has been tagged “IT.Wox” on the blog). Or take it a step further & pull content based off the visitor’s browsing history (e.g.: pull content on “.NET” if the user has been searching on that term & we have Google and/or some other social behavior tracking software provide that context).

While the whole behavior tracking seems cool, we need to be cognizant of visitor privacy (which is a whole different post at a later time). Besides, what if the user has been searching for furniture during this holiday season & lands on this site out of some twist of fate? Do we show him a blank in the blogs as we (usually) will not have any content related to furniture?

So, the choice was simple – pull by tags at a later date (when we build up sufficient content) & till then latest 3 postings it is.


At this time, this site contains the bare bone minimum amount of content & information needed. Over the coming months, we will expand both the content & the functionality of this site to better fit our needs. However, we are confident that the current design should hold for most of our use-cases & would love to hear your comments/feedback about this new look.

Is there any aspect of this site we should have styled differently? Do you like/hate it? Feel free to sound off in the comments & continue reading the remaining parts of this series.

Read the Series:

New Year, New Look

The IT.Wox site has been dormant for a while & the site had gone stale.

Just in time for the New Year 2016, time to refresh & reboot!

So, here’s presenting the new look site:

The Goals

  • Highlight what IT.Wox stands for (aka. motto/USP/theme)
  • Highlight the services/products of IT.Wox (aka. what we do)
  • Highlight some interesting aspects of the site (via Blog, News, Social etc.)
  • Support mobile & desktop browsers (gracefully degrade, where possible)

The Subtle Text

Being that we are a start-up (of 2 people, part-time!), the design had to be done in-house or rather by your’s truly. With $50.00/year (or less!) operating budget, the site has to deliver a message on a budget!

However, we need to support latest “web presence” requirements:

  • A mobile-first website
  • Branding & messaging
  • Social media presence
  • Site Analytics
  • Communications & interactions with web visitors
  • Modern web development standards (build – test – deploy)
  • Source control, Issue Tracker & Build Management
  • Scalable Infrastructure
  • Legal needs like privacy policy, disclaimers etc.

The Subtle-er Text

This site is an expression.
Of what we can do, of how we can do it & our whole philosophy/approach to the business of IT as it applies to consulting & development. It is an expression of our vision of a company & what we hope to achieve.

This site is an experiment.
Of technology, design & integration of various components which are needed for modern web development. In that sense, this site is not finished (& might never be!), we hope to keep it going forward each cycle to the next version with better improvements to reflect our current understanding & thinking about this business.

This site is an experience & instruction.
Of the details needed for running & maintaining a simple web site. While the scale is small/micro, the complexity & approach is still the same as any of the large site/applications out there. We will surely learn – from our experience, feedback from this site & other channels, to make it better. However, we could also be a source of knowledge for other developers out there & starting out on similar endeavors.

The Next…

In the following few weeks, we hope to post some of the interesting aspects of this site, few implementation details & hope you will read along and/or provide comments where due.

Happy New Year!

Read the Series:

I love to Grunt & Gulp

Task Runners – like Grunt & Gulp are such time-savers!

Reason: Automation!!!
Remove the “grunt work” by making tasks repeatable & standardize build/deploy scenarios, win-win!

Now, I am sure many of the savvy techies in you would have already checked out Grunt/Gulp and using them in your own ways. Task Runners have been in the wild for some time now, with excellent tutorials to get you started & so I will not delve into the details of how/what/why of these items.

The point of this article is for an interesting thought I had:

  • Is there any real need for such a framework(s) in your code in the first place?
  • Aren’t we introducing additional components + complexity into our code by having such items?

Is there an alternative to get the automation benefits of Task Runners, without the need for additional complexity and/or bloat of adding such frameworks into your code?

When this thought occurred to me late last night (yes, during a New Year’s Eve Party & yes – I am THAT kind of nerd!), I just could not wait to get started & give it a twirl in the NPM world & see where I get to.

More specifically, I was thinking of code along the lines of:

// code in package.json
scripts: {
"build": "npm build:script && npm build:css && npm:deploy",
"build:script": "browserify src/index.js -o dist/lib.js",
"build:css": "less"

As soon as I started along these lines, a small voice in my head went:
did someone think of such a solution before & if yes, what does that code look like?
Answer: Google says someone already has got there first.

As I tip my hat to the master, I also realize that I have been 2 months 1 day slower in coming up with this thought & 23 days slower in publishing a solution


I would strongly recommend to read through his material before continuing.

My personal opinion is that he is on to something here & I do see all the benefits in the solution.

Question: will I use the proposed solution in my own code-base?
Answer: While I really like the solution, is it worth the cost of readability for someone to “get” what it really stands for? I don’t know.

I will let this one simmer for a while & eventually wean off Grunting/Gulping.

I am too much in habit at this point in time.

Happy 2015!

Code Craftsmanship, is dying

A gloomy title, no doubt, but reality is Code Craftsmanship is indeed dying.

The Lament

Gone are the days when a developer would come in to work & not worry about going home till the code works, code comments meant something, the unit tests were written & passed.

Gone are the days when developers knew what code they had written & could recite it backwards if needed.

Gone are the days when the developer read other developer’s code like you would read the latest thriller novel.

Gone are the days when there were these “Coding Oracles” who knew everything about how to code & you stood in awe in front of them eager to learn & see how the genius went about doing his magic.

The Commercialization of Coding

Coding is now a commercial activity. Developers are the “machines” which are expected to churn out code faster & faster to meet the every demanding & insatiable appetite of the new “digital world”. Where is the time for deeper thought, reflection & impact analysis?

Commercial (a.k.a $$) interests is the name of the song & coding purity is just a wrong note which needs to be avoided for the symphony to be complete.

How many times have you heard a developer say: “I could not finish unit testing/review/documentation/commenting as I had to do (blah blah)”.

Sure, we can blame the developer for being lazy/late or the $$ being more important or the market timing being the more important factor etc. etc. for missing out one of the core components of any development activity.

Sure, we will also feel GREAT for the arguments we present for NOT doing something.

But, have you ever gone back to the original project plan & saw the contents of the plan?

In my recollection, I have NEVER seen a project plan without time being allocated for analysis, unit tests, reviews, documentation – all the fine things which make code complete.

Then why is it that the usual end product of the the effort is lacking these aspects? Where is the time, promised in the plan,  lost?

This is what I term as the “commercialization of coding” where developers & their leads, project managers, product owners – tend to think software (especially modern software) as having reached a level of maturity where these basic items can be missed & yet you will end up with a stable finished product.

No – it cannot be & it will not be, at least not till we define “Professionalism” in coding.

Professionalism in Coding

Traditional crafts like: plumbing, carpentry, masonry, architecture & construction, the auto industry have had a huge head start over IT.

While these industries are mature in the sense of their basic guidelines & principles, IT & consequently coding is still an evolving field where we are still learning new ways of doing things. Better processors, dual/multi-core processors are forcing us to think of new ways of writing our code to harness the powers unleashed.

But, unlike the traditional crafts where the apprentice has time to gain experience & expertise before he is given the immense responsibility of moving up the ranks, it is relatively easy in the Coding world to move up – especially if you are one of the so called: “knows the latest technologies”.

Unlike traditional industries where an building Architect will get sued for even a small design flaw in the construction of a building, Software Architects file everything under the guise of a “bug” & set priorities & release dates of when the bug will be fixed.

Don’t get me wrong – software development is an extremely “intellectual” activity with perceived easy of fixing issues and/or changing designs as compared to a physical building, but if we really look at the vast majority of implementations, it is painfully obvious that “Professionalism” is missing.

Professionalism – is the ability to be true to your craft & take all the steps necessary to know it to the best of your abilities & nurture, practice & hone your techniques over & over again before doing it on a real project.

Come to think of it – how many of you would feel confident if you were the very first patient of a dentist who passed out of college recently? Apply that to software – how many of the software architects today are designing highly complex systems on a completely new technology for the very first time as a “new & challenging opportunity”?


Commercial interests will continue to rule (& fund) projects, make no mistake.

But, what can you do so that even if you are part of that mill – you are being true to the business? Practice, practice & more practice is the only way IMO. Make your mistakes when you practice & reserve your flawless performances when you code in real life – the commercial interests expect it.

Before I sign off, please browse the following which echo some of the same sentiments:

Software Craftsmanship & Code Retreats with Corey Haines

Software Craftsmanship

Jeff Atwood in his indomitable style:

Prediction is very difficult…

Prediction is very difficult, especially if it’s about the future – Niels Bohr

I was reading an extremely interesting article about the Theory of Disruptive Innovation. Needless to say, Steve Jobs features prominently when we look up any material in this area.

Let me point to one such article which talks about how Steve Jobs solved the Innovator’s Dilemma.

I am not your typical iFanBoy, but you need to respect what the man achieved in his lifetime. The impact of the iPhone/iPad/iMac has been so profound that any literature about disruptive innovation is quite incomplete without understanding the workings of the mind of Steve Jobs.

At this point, I want you, my dear blog-reader, to read an interview of the person who “influenced” Steve Jobs & may I ask you to pay close attention to the last 3 questions in the article – which brings us back to the real purpose of this article, enjoy 🙂

Technical Debt – time for payback!

The US economic outlook is looking bleak & the markets are going flip-flop everyday since the S&P credit-rating downgrade – all of this in response to the US Nation Debt of over $14 trillion & counting!

Do you know, as developers, what is the Technical Debt in your code-base?

Have you been able to estimate, measure, track & payback this debt before it becomes a burden & you too face a credit-rating downgrade by your customers?

Surely, the popular Project Management tools like – TFS, Jira, MS Project etc., should be able to tell you these metrics?

No? Think again

What is Technical Debt

This article will not focus on the definition of Technical Debt, there are tons of well-written articles out there with more details than I can ever hope to cover. Some of the most useful links I have referred to while writing this article are:

Technical Debt – a basic primer from Wikipedia

Technical Debt – the different kinds of debts & more depth in understanding

Technical Debt Quadrant – by Martin Fowler, prepares the kind of mindset needed to address this topic

Paying down your Technical Debt – by Jeff Atwood, a good article to understand why paying down is so important

Is Technical Debt still a useful metaphor? – interesting read. I think the term is even more relevant today than before, but this article has an interestingly different view point.

With the education out of way, my focus for this article is to put forth some practical steps & techniques I have used in my previous projects to pay down Technical Debt.

Robert McIlree has proposed a method to measure Technical Debt. But like the author mentions – some of the parts are based on approximations & we need a more solid method to estimate & project the costs.

Raj Anantharaman mentions another technique using TFS for the measurement & graphical representations.

The technique I am putting forth below is a mix of both Robert & Raj’s work – but generalized to work with any Agile or non-Agile process you might be using & independent of any tools.

To bell the cat

Let us consider a project (Agile/non-Agile does not matter) which has a list of business requirements.

This list can be called a Product Backlog (Agile) or a Business Requirements Document (non-Agile). For simplicity of explanation, let us use the common terminology of Product Backlog to mean both the Agile & non-Agile description of this list.

Along with the Product Backlog, create another list called the Technical Debt Backlog – which, at the start of the project, might be a list of the Technical Debt inherited to the team like: existing services or code-base being used as part of the project, existing schema’s etc. If you are lucky enough to start from scratch, this Backlog will be empty.

Now, for every Sprint/Release/Iteration, record all the items which are termed as Technical Debt as line items in the Technical Debt Backlog.

Estimate & prioritize the Technical Debt Backlog the same way as you would any of your Product Backlog items & you are on your way to Technical Debt freedom!

For the Mathematically-minded

Here are some interesting metrics which can be generated from the Technical Debt Backlog

Table 1: Technical Debt Metrics
Metric Description Units
Debt per release The measure of Technical Debt items introduced into the code-base per release number
Debt per resource The measure of Technical Debt items introduced into the code-base per resource number
Debt Reduction Velocity The measure of Technical Debt items closed/released per release number
Debt Aging The measure of how long the Technical Debt item was sitting in the Technical Debt Backlog before it was taken up in a release Days
Debt Cost The measure of how much the debt costs Man days

These calculations are simple & straight way of looking at the Technical Debt in your project by listing out the items explicitly, estimating & prioritizing them & having your team work on these items.

Technical Debt – like all debt items – can be a very powerful tool to meet your short-term deliveries.

Similarly like all debt items, the longer you have Technical Debt in your code-base, the more interest it gains & the more expensive it is to payback what you owe.

Beware & take care!