Developer’s Intuition – Why You Should Listen to Your Instincts

What do you picture when you think of a stereotypical programmer? Probably a dark room, dimly lit by computer screens, the coder is hunched over with his face almost in the screen. You hear wild typing and numbers and letters are flying along the screen. How does our stereotypical programmer approach an issue? I’m pretty sure society hears him spouting off which algorithm he’s going to use or the exact schema that his APIs are going to be using. I’m not going to lie, that’s how I figured I was supposed to be acting – approaching the problem with an analytical approach, using the proper words (although I always got them wrong) and trying to stick to a script. That all changed with what I call *the problem*.

Hunch is a real thing. Who knew?

It’s a late afternoon and I’m wrapping up my day’s work when the voice of Vina pipes up behind me. “Hey Al, I’m seeing some weird behaviour. Can you come take a look?” I glance behind me and notice she’s rather concerned. The look on her face is exactly what you don’t want to see right before the end of a day. I wander over and she shows me a series of steps on the app. It’s not good.

It ends up being a late night, but together, we resolve the issue. I’m annoyed, but not because of the extra work. What really gets to me, is that I had been working on this code base for years. The issue had been present for quite a while, a lot longer than I was there. In hindsight, there was plenty of time to spot it and deal with it, yet I never did. How could that have happened? After all, the signs that something was off were there…

When code seems suspicious, that’s because it is

I remember the first time I noticed something was wrong – I was working on refactoring and wanted to eliminate a chunk of code. Unfortunately, a function I was used to having wasn’t available. Instead, I had to work with some older code that wasn’t doing quite what I wanted. I looked over at my co-worker and asked a quick question. “It’s always been like that,” she said. Although it didn’t feel quite right, the current state of the app was working, and being brand new to the code base, I decided to place trust in the previous coders.

Few months later, I run into the issue for the second time when I was streamlining a major feature of the app. I was consolidating code that was reused in a couple other places in the app to make it more accessible to any future coders. While I was testing my changes, a section of code that I messed up was exposing some unusual functionality.

For about a week, while I worked on the new code, I kept asking “Why does it keep doing X or Y when it breaks? Shouldn’t it be doing Z?” Again, I had that hunch saying something else was wrong, but at the time, there were more important things to worry about. The weird functionality will surely go away once I was done fixing what I was working on, right?

The last time I ran into the problem, we were under the gun to get a release out the door. Our testers had found a series of steps that triggered a curious bug. Once again, I’m sitting at my desk, fixing things and wondering what caused this bug in the first place. Even though I soon resolved the problem, my instincts were telling me that there may be a deeper-rooted cause behind it. This time, we had plenty of other things to get done before the release, so there was no time to investigate. It was probably nothing anyway.

Intuition is a skill, so trust it.

Well, it wasn’t nothing and the issue just kept haunting me. That final bug was eerily similar to what Vina discovered and showed me. Each time I brushed up against the problem, I had that feeling in my gut. It kept telling me something was wrong, yet there was always a good reason not to trust my intuition – I was too new, it wasn’t what I thought it was, or we didn’t have enough time to look into it. Since I didn’t trust myself, the problem existed for far too long when it could have been resolved much earlier. I had plenty of time to fix it.

As developers, we’re naturally rational and analytical. The love for science and math is what got us here in the first place. We analyze a problem extensively and come up with a proper solution. While that’s a great way to approach problems, sometimes we just need to trust ourselves, our experience, and our instincts. You’ve been taught what you need to be a developer; you’ve seen multiple different applications and approaches and been successful many, many times. Trust yourself.

How to Avoid the 3 Classic Pitfalls of Writing an RFP

As the person who authored the RFP, there’s nothing more frustrating than reading vendor responses that are all over the map, making you wonder if anyone even read your document. How could they have misunderstood so much? Why did they give you so little detail about the very thing you were asking for? Meanwhile for the respondent, sometimes what’s being asked is a mystery.

When it comes to how to write an RFP (Request for Proposal), or an RFI (Request for Information) or RFQ (Request for Quote), it’s as much about the art of communication as it is about the technical details.

1. What is it you need again? – Clearly define the vision for the RFP

While most RFPs have a section up front for vision and need, surprisingly few use it in a clear way. Unfortunately, that rarely leaves the reader prepared to absorb the rest of the document.

All too often, the stated vision and need are tangled together and written so vaguely, that they are a missed opportunity to provide context for everything else to come in the document. Even if the responding companies have experience with your organization, the person or team responding to the RFP may or may not need a refresher. Stating a vision is great, but don’t forget to state clearly what it is you need. It doesn’t matter if it’s a paragraph instead of a sentence, as long as it is clear.

Consider the typical example:

“Our aging customer portal provides self-service functionality. We are looking to apply lessons learned and expand our business.”

Versus a clearer:

“Our existing customer portal centers on self-service functionality (e.g. placing and tracking orders, logging support tickets). Its technology is coming to the end of life. We are seeking a replacement that provides more than like-for-like functionality. We will be incorporating lessons learned in terms of improved user flow, business processes, as well as offering three key new services: X, Y, Z.”


2. Understand What You Actually Completed – A Dive into Requirements Gathering

As much as possible, we all want to provide responders with enough information to help drive down project cost, risk, and timeline. In doing that, requirements gathering may be done internally, which can be quite helpful. However, all too often, project owners state in the RFP and firmly believe that the requirements gathering stage is complete. This misses a few key understandings; let’s quickly delve into a couple of them.

Building context and confirming needs

Even armed with the best internal requirements, the successful vendor will likely need to build context with the business to properly understand the requirements. One reason for this is building relationships between the vendor’s team and the business. However, what’s more important, is surfacing implied assumptions that can have a significant impact on complexity, risk, and the timeline.

Different Process, Different Mindset

RFPs are a vehicle for inviting responders to provide expertise in areas that we don’t specialize in. This means that vendors will likely ask different questions that align with their process, which helps reduce the chances of surprises later. Remove this time in the RFP, and you’ll find it secretly showing up in design or somewhere else.

If you’ve gone through a requirements gathering exercise, this advice isn’t about letting the vendor then redo the entire thing. Rather, expect the responding proposals to have adequate time in their proposal to review, clarify, and confirm what was internally discovered.

3. The Most Assumed Away Requirement of Them All – Secret to Controlling Costs

Last of the 3 classic pitfalls for this article is forgetting this one vital requirement in any software RFP. Many clients assume or think it is self-evident that this one functionality is needed, only to realize that the responders took it out of scope and out of cost. Worse yet, sometimes even when the functionality is clearly stated, responders wrap it up under assumptions. That requirement? Migration.

Replacing an existing system with a new one is never a simple task. However, it is easy to forget that moving content from a legacy system to the new application can dwarf the implementation cost if you’re not careful. Migrations are fraught with complexity and risk, which is why unless it’s explicitly called out, many responders will not put them in scope.

When you’re planning on putting in migration details, it’s worthwhile doing an exercise to help determine what’s the likely percentage of the content that’s needed. For example, consider if you need every file from 2009 onwards, or does your organization only use 10% of that? Do workflows need to be mapped form the old system to the new one? Or, will that work be closed out before migration? Answering these questions in an RFP can reduce complexity, add clarity, and help responders better evaluate the risks and costs.


The best advice above all others?

Write the draft of your RFP from your point of view, then revise it from the responders’ perspective.

Looking at it through their eyes will help you identify areas where you are missing context, hiding assumptions, and setting yourself up to get a response that isn’t exactly what you’re looking for.


Need help with building or replacing a software application? Discover how we help our clients leverage technology to meet business needs.

Webpack: The Basics

“The mechanic that wishes to perfect his work must first sharpen his tools.” – Confucius


A few weeks back, I was chatting with some of my coworkers about how quickly a developer’s toolset changes. It wasn’t that long ago, when we were building web applications where the pages were rendered completely on the server. The rendered HTML was then sent to the client with a nice helping of view state to increase the page size. Times have changed, and more developers adopted client-side scripting. Our jobs got progressively easier with the emergence of JavaScript frameworks like AngularJS and React for client-side development and the evolution from ASMX services, to WCF services, to RESTful APIs on the server-side.

This progress, however, does come at a cost as it requires some knowledge of the tools that make dealing with these frameworks possible. The conversation I was involved in a couple of weeks ago was centered on webpack and how it’s used and configured in our current projects. Webpack comes pre-configured out of the box on a lot of the newer default Visual Studio project templates. You don’t need to know anything about webpack to use it, Visual Studio conveniently hides most of that from you. That is, of course, until you need to update a package which requires a newer version of webpack. Which breaks webpack. Which has happened to all of us at least once or twice.

I put together a lunch time training session for my coworkers (and really, for myself) to figure out what webpack is and how to use it. What follows is a short introduction and a set of demos I did with my coworkers that ran us through the very basics of webpack to a somewhat more complex example that mirrors a good part of the functionality you get out of the box in a Visual Studio project template.

What is webpack?

“Webpack is an open-source JavaScript module bundler.” – Wikipedia

Webpack can be used for the following:

  • Automation (task runner)
  • Minimize CSS (bundling)
  • Minimize JS (includes transpilation and bundling)
  • Bundle images (and other assets)
  • Watch a project for changes and re-bundle

Similar Tools (there are many, many more)

I won’t bother going into too much detail, but there are many other tools that do similar things. A few of the more well-known ones are listed below:

Grunt – the JavaScript Task Runner


Parcel JS

What do I need?

  • js
  • yarn
  • Text editor (I recommend Visual Studio Code)
  • js (we’ll take care of this in the demo code)
  • Patience (you’re on your own for this one)


What is node.js?

  • js is an open source server environment
  • js is free
  • js runs on various platforms (Windows, Linux, Unix, Mac OS X, etc.)
  • js uses JavaScript on the server


What is Yarn?

  • Yarn is a package manager for the JavaScript programming language
  • created by Facebook
  • new kid on the block (relatively speaking, of course)
  • Yarn caches every package it downloads so it never needs to download it again
  • more secure (verifying packages)
  • originally the only package manager that included a lock file

Demo 1 – Use Yarn to install and setup basic webpack bundling

In this demo, we’re going to build a simple webpage that references a bundled JavaScript file built from two different JavaScript files. This will give you an extremely basic idea of what webpack offers.

Open up a PowerShell window, create a new folder for the demo, and navigate to that folder:

  mkdir webpack-demo
  cd webpack-demo

You’ll notice that it created a new file called “package.json”. This file keeps information about your project. It should look something like this:

Webpack demo package - package.json

Now we have to add webpack to our project. Type in the following command:

yarn add webpack webpack-cli -D

Yarn is now adding two packages to our project: webpack and webpack-cli. We need webpack-cli so that we can run webpack from the command line.

Now let’s open this folder in windows explorer:

You’ll notice that there is now a “node_modules” folder and a yarn.lock file added to our project.

Let’s head back over to Visual Studio code. If you look at the package.json file, you’ll notice that we have a new section called “devDependencies” added to our file. It lists both webpack and webpack-cli. The “-D” in our previous Yarn command told Yarn to install these dependencies as development only.

Webpack Demo 1 - devDependencies

Now, let’s have some fun! Inside Visual Studio code, create a new file called “main.js”

You can put whatever JavaScript you want in here, but I like to keep it simple. This was the content in my main.js file:

console.log("Hello from main.js!");

We’ll create another file called “main2.js”. Here is the content in my main2.js file:

console.log("Hello from main2.js The second file!");

And finally, we’ll create a third file called “index.html”. I like to use the Emmet abbreviation feature in Visual Studio code, so as I type “html” I’m able to click on “html:5” and have an HTML5 compliant template auto generated for me.

Webpack Demo 1 - HTML5 compliant

You can keep all of the defaults, or you can change the title, it is totally up to you.

Add a script tag to the head of the HTML document and set the source as “bundle.js”.  (don’t worry that it doesn’t exist yet)

<script src="bundle.js"></script>

Here is my complete index.html file:

<!DOCTYPE html>
<html lang="en">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Webpack demo!</title>
<script src="bundle.js"></script>

Save all three files and head back to the command line.

Now we’re going to use webpack to generate that file “bundle.js” for us. Type in the following command:

node .\node_modules\webpack\bin\webpack.js main.js main2.js --output bundle.js

Here is the output:

Webpack Demo 1 - output

We are essentially telling webpack (which we are running via node.js) to take “main.js” and “main2.js” and bundle them together and output them into one file called “bundle.js”. You can ignore the “Warning in configuration” for now; in a later demo I will show you how to get rid of that message.

If you look at the directory now, you should see a file called “bundle.js”.

Webpack Demo 1 - Directory bundle.js

Open the index.html file in Chrome and have a look at the developer tools. You should see your console.log messages!

Webpack Demo 1 - index.html file

Demo 2 – Use webpack config for more automated bundling

In this second demo, we’re going to build a simple webpage that (again) references a bundled JavaScript file, but this time we’ll be using a configuration file to tell webpack what to do.

Open up a PowerShell window, create a new folder for the demo, and navigate to that folder:

mkdir webpack-demo
cd webpack-demo

As we did in the last demo, use Yarn to create a basic project in this directory and then add the webpack and webpack CLI packages:

yarn -y init
yarn add webpack webpack-cli -D

Let’s open the current folder in Visual Studio code (or whatever editor you prefer) by typing:

code .

Create a new folder called “js” and add three new files called “file1.js”, “file2.js”, and “index.js” inside the newly created “js” folder:

Webpack Demo 2: JavaScript Folder

Type in the following text for file1.js:

console.log("initializing file1.js");
export default {
  hello: function() {
    console.log("Hello from file1.js");

Type in the following text for file2.js:

console.log("initializing file2.js");
export default {
  hello: function() {
    console.log("Hello from file2.js");

Type in the following text for index.js:

console.log("Hello from index.js!");
import file1 from './file1';
import file2 from './file2';

At this point, we have 3 JavaScript files -> index.js is simply importing file1.js and file2.js and calling their respective “hello()” methods.
We still need to create our index.html file and we’ll do that in the same fashion as we did in the previous demo. If you’re using Visual Studio code, simply start typing “html” and let the Emmet abbreviation feature finish the HTML5 compliant template.

Webpack Demo 2 Emmet Abbreviation

Add a script tag to the section (don’t worry that the source “dist/bundle.js” doesn’t exist yet, we’ll fix that with the magic of webpack!):

Here is my complete index.html file:




Now add a file called “webpack.config.js” to the root of our project. Save it with the following text:

const path = require('path');
module.exports = {
  entry: './js/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'

Just to explain what we’ve typed into the webpack.config.js file:
“entry”: This is the initial file that webpack will start processing. Any references (imports) to other files will automatically be parsed and included in bundling.
“output”: This tells webpack what filename to use for the bundle (in this case we actually called it “bundle.js”) and it also tells webpack which path to use to put the output (we are going to store our bundled file in a “dist” folder).

At this point, we can go back to our PowerShell window and type in the following command:

node .\node_modules\webpack\bin\webpack.js --config .\webpack.config.js

This command is similar to the command we used in Demo 1, except we’ve simplified things considerably by specifying a configuration file for webpack to use.

Here is the output:

Webpack Demo 2 - PowerShell Output Bundle

There is one additional shortcut we can add at this time – instead of having to type out the whole “node .\node_modules…” command, we can add a section to our package.json that defines a shortcut for us. Open the package.json file in Visual Studio code and add the following “scripts” section after the “devDependencies” section:

  "scripts": {
    "webpack-it": "node ./node_modules/webpack/bin/webpack.js --config ./webpack.config.js"

Your package.json file should look something like this:

Webpack Demo 2 - Json package

Once you have saved the package.json file, go back to PowerShell and type in:

yarn webpack-it

You’ll see that the output is almost identical to the output we saw when we typed in the full “node .\node_modules…” command. I gave my command a fun name of “webpack-it”, but you can use whatever name you want. The “scripts” area is a great place to store your custom commands for running unit tests, packaging of vendor files, etc.
Now let’s test and make sure our bundled JavaScript file works! Open index.html in a browser and you should see the following in the developer tools console:

Webpack demo 2 - index.html file

Demo 3 – Configure webpack to watch for changes (and get rid of that “mode” warning in the output)!

(This demo builds on the files created in the previous demo) 

You may have noticed that when you make changes to either of the JavaScript files (“file1.js” or “file2.js”) you have to retype the command “yarn webpack-it” in order to re-bundle the files.

Add the following line to the “module.exports” section of your webpack.config.js file:

watch: true,

Your webpack.config.js file should look like this:

Webpack Demo 3 - Webpack Config

Now when you type in “yarn webpack-it” in your PowerShell window, you’ll notice the line “webpack is watching the files…”. This means that any change to “index.js”, “file1.js”, or “file2.js” will result in a re-bundling of the output file “bundle.js”.

Webpack Demo 3 - PowerShell Output bundle

Try it out for yourself! Refresh your browser window to make sure everything is still working as expected (you should see the same output in the debugger window as we saw in the previous demo). Now make a change to “file1.js”, I chose to change the “console.log” in my hello() method to say:

console.log("Hello from file1 * Updated * .js");

You can verify that webpack re-bundled your JavaScript by refreshing your browser window and checking the output in the Developer Console:

Webpack Demo 3 - index.html file

The final part of this demo involves removing the “WARNING in configuration” message you’ve been seeing during the webpack bundling operations. Add the following text to the webpack.config.js file:

mode: “production”,

Your final webpack.config.js file should now look like this:

Webpack Demo 3 - Final Webpack Config

Go back to the PowerShell command prompt one last time and type in “yarn webpack-it” and look at the output. You should notice that the “WARNING in configuration” message is now gone.

The value “production” simply tells webpack that you want to bundle the JavaScript together and minimize the bundled file. In a development environment, you can specify “development” instead of “production” and webpack will still bundle your files together, but it will bundle them un-minimized. I’ll leave it up to you to try that out and look at the output “bundle.js” file.
I hope this article was useful in seeing how powerful webpack can be by breaking it down into some small simple demos. From here, I would suggest trying to add some CSS (or SASS) files and adding a css-loader to your project and configuring webpack to process those files too. I found that by doing it in this manner, I was able to start troubleshooting problems that both I and other developers were having with our Visual Studio “out of the box” template build solutions. Something that seemed quite complicated at first, is now less confusing and significantly less daunting.

Quick Setup: VSCode and TypeScript

TypeScript can hardly be called a new kid on the block anymore but plenty of people still haven’t knocked it off their “languages to check out” list. So, here’s a quick and dirty guide to setting up VSCode for some TypeScript experiments to get you going. Read more

Quality Conf 16.2 Recap: Introduction to React

On December 16, 2016, DevFacto hosted Quality Conf 16.2 – a full-day internal conference dedicated to learning and team building.  A number of sessions were presented by our team members which focused on everything from personal to technical growth.  In this post, we recap “Introduction to React” which was originally presented by DevFacto consultant Chris Nissen. Read more

How Workshops Work For Us

When starting a project there’s a million things to do but little time. Productive meetings are tough at this stage. At a previous client site, a colleague and I went from zero knowledge to having a comprehensive set of features for a mobile app in a single day. Over the course of that day, our group of ten people discussed perhaps hundreds of small features, came to consensus and decided on the relative importance of each idea. After the workshop, participants were enthusiastic and energetic. Someone even said that the day flew by. Here’s how we did it: Read more

Bug or Opportunity?

So you’ve built something neat and it’s heading to production soon.

You’ve got pretty good test coverage and your tests are meaningful. You tried to break it as much as you could and couldn’t find any show stopping bugs. You’re proud of your work.

The customer should be grateful to have someone so thoughtful and… uh oh, the customer just sent you an email titled “NOTHING WORKS IN PROD! PLEASE FIX”. All caps can’t be good. Read more

Industry Trends: 2015 Summary

As consultants, we get opportunities to work with a variety of clients in different industries. We’re often advising and helping with new ideas and technology and it’s critical that we are up to date and aware of industry trends. Read more

Thinking in the New World of Technology

Technology is constantly changing not just the way we do business, but also the way we think about doing business. It is no longer enough to simply “keep up” with technology or maintain the status quo. What worked in the past, what works now, may not be what sets you apart from competition in the future. Read more

QualityConf 2015

I had an amazing time at QUALITYCONF. I will jump at any chance to sketchnote some great topics from engaging speakers, and QUALITYCONF did not disappoint. This DevFacto event happened from March 27 to 29 at Stone Ridge Mountain Resort in Canmore Alberta. Read more