Using GulpJS

I recently gave a talk at the St. Louis Angular Lunch on GulpJS. While not directly related to Angular, GulpJS is a great utility to have while working on frontend development, and it very popular among Angular developers. This talk explains the basic usage of Gulp and provides some minor comparisons to its largest competitor, Grunt.

Here is a video of the talk, from our YouTube channel.


Here is the talk, transcribed to text. This is a lightly edited, draft transcription, so any errors are probably from that process.

Continue reading Using GulpJS

Beware of Prototyping

There are many threats to a successful software development project. While prototyping seems on the surface to be a 100% wholesome and good thing, it does need to be used wisely and be properly qualified, or it can become one of those threats. Like other aspects of project development, prototyping needs to be done well and with purpose.

Prototype vs. Mockup (wireframe)
This article refers a lot to prototypes. In our model we differentiate very specifically between mockups and prototypes. We will often sketch up a screen on a whiteboard or in a tool like Balsamiq. These are useful for getting buyin for a layout or a specific concept. This is a step or many in the development of the prototype. These sketches become archived in the project history within design docs and JIRA issues.

We view the prototype as a specific deliverable. It is where the vision for a project comes together. Where we communicate the following things to our clients.

We understand your problem
We know how to solve your problem
We are really good at this
Imagine your team using this tool

On the surface this may seem at odds with the article itself. The key is to establish realistic and accurate answers for the client to the obvious questions we are answering in our communication. The executive team will enter a presentation with at least a subset of the following questions:

Do they really understand my problem?
Can they solve the problem?
Did we pick the right team?
How will this work?

Mockups and wireframes will not answer these questions. This is why we deliver a working prototype that uses dummy data to emulate what the app will deliver. We gain incredible feedback and make the project “sticky” when we successfully do this.

Many times a non-technical customer will see a prototype and mistakenly assume a certain level of completeness. After all, here is a piece of software approximating a subset of what they want. It works, right? bigstock-Mobile-Web-Design-And-Developm-52160128Surely it can’t take much longer to complete since they are this far? There are many ways to combat this, but often this assessment is not even conscious. Our minds assess and categorize all day long. Later in the project a misunderstood prototype can damage your relationship with the customer.

Most organizations struggle to be responsive enough to even deliver a prototype. Such an organization needs to strive to achieve this. It is a valuable skill to have in your toolbox, one that can help you win large, complex projects. A prototype allows you to demonstrate your depth of understanding of the problem, showcase your creativity, and validate your mastery of your tools. It is also an opportunity to introduce a new and hard to explain concept that might really turn a good project into a great one. These are all tremendously important reasons to build prototypes.

I have talked in the past about the tension that occurs in a project right before it is first delivered. The stakeholder cannot see into the opaque world that we are working in, and has to believe us when we tell him there has been progress. You can use issue trackers, fancy charts and graphs, even code reviews, but the truth remains: the customer is trusting you. That dark period, right before the customer has something tangible to test and evaluate, really exposes any weaknesses in your process, including poor prototyping.

In a typical application there are some core business processes and rules that drive the business needs. These are implemented, executed, and supported in a server-side application. This application might parse requests, route work, accept/calculate data, generate complex results based on inputs, or prioritize based on business rules. These efforts are typically where most of the work occurs, coding all of these processes is time-consuming and detailed work.

The user interface is often partially or wholly generated by a framework or ide and takes much less time. BUT, the user experience is what the typical executive or user at your customer will care about the most. It is also the most graphical/visual component of the system where users will interact with vital business processes. By default, this is typically where we prototype. This is the correct place to prototype but we have to be careful. We have to communicate to the customer the mountain of work required to turn a prototype into production code.

Just like a customer only hears the dollar amount when you give an estimate no matter how you qualify it, customers rarely comprehend the shell you are demonstrating to them in your prototype demo. Because, “How much longer can it possibly take if I can already see x, y, and z on the screen?” I have learned to display a complete project progression graph along with a prototype. You can see an example of one below. This does not solve the problem, I know I will still be asked later. But I will be able to refer back to a visual description that shows just how little of the project is done to generate the prototype. It is very important to not just have said the words, provide a visual that is stamped in their memory along with the fancy eye candy you are showing them in the prototype.


You cannot avoid tension from a well done prototype. Remember, a successful prototype will  excite your customer, it will demonstrate for them the direction you will take in solving their business problem: how you will fulfill the promise you made by accepting the project. Just do not be naive and think there is no risk with a prototype because there certainly is. In fact I have watched it derail multiple projects over my career.

Another thing you learn about prototypes as you gain experience is to temper what is included. It is often tempting for the younger tech designer to want to show their full arsenal and impress the client. A prototype needs to be a very intentional and calculated deliverable just like any other. Filter what you show them by understanding your goal. Make a prototype purposeful, this can mitigate an unexpected consequence later. One example is when you find out the CEO was focused on a specific secondary graphical element that got nixed early on in the project. You do not want to be explaining why his favorite thing is gone because it was included in a poorly thought out prototype.

The message is to not let your guard down. A prototype, like any other aspect of your work needs to be done with a high level of precision. Prepare your prototype like you would any other feature, with intentional goals and outcomes. A defined set of criteria can make your life much more pleasant later.

Code Reviews – Use a gate, not a drive-by

Does your team / project use code reviews? If not, I suggest starting today. There are countless resources online about how and why to do code reviews; there are numerous code review tools, open source and commercial.

Who should review code? A great question, perhaps for other blog posts.

When should code be reviewed? Hopefully also great question, and the topic of this blog post.


When making a recommendation, I’m trying to get in the habit of always mentioning the context, the situation in my work from which my recommendation arises. This is in response to seeing frustration when people try to follow advice, not realizing that their situation is completely unlike that of the writer.

Here ate Oasis Digital our context is mostly complex line-of-business applications, which are expected to live for a long time and are important to the business operations of the companies that use them. We are almost always replacing an existing system (which a company relies on) or expanding an existing system (which a company relies on).

Another critical part of our context: we have flexible and fast source control, and a group of developers who have learned how to use it competently. We have decoupled source control from build automation, so that we can perform builds of branches in progress without merging them to a mainline. We can achieve a sufficient degree of continuous integration without actually putting each change directly into the same code line.

Review Code Early

How long after code has been written should it be reviewed? Hours or days, not weeks. For this reason, we commit and push code frequently (to a disposable branch of course) where others can see it for early review. It can be a challenge to get past the ego-driven desire to make code perfect before exposing it to the scrutiny of others, but it is worthwhile. By exposing code to review and comment early in its life, a developer can get useful feedback early in a unit of work.

peer-reviewReview Code Often

Another anti-pattern of code review is to look at a given proposed change only once or twice. That is sensible for a very small change, but for a complex change to a complex system it is best to perform code review repeatedly as work proceeds. For example, consider a feature that takes four weeks to implement. Our typical approach, which I recommend to others (if their context is reasonably similar to ours, see above) is something like this:

  • Review the code a few days in.
  • Review the code progress once a week or so.
  • Review the code when it is nearly ready to be called “done” and to go in the mainline.
  • If there are fixes needed, review those promptly so as not to cause delay.

Review Code Now

Code waiting for review is a drag on the speed of development; the right time to review code is now. A quick review now is probably more valuable than a deep review deferred.

Review Code as a Gate

In some organizations, code review happens asynchronously and sporadically, after code is already part of a project. This risks software quality collapse. Once code is in the mainline of a product, it is arguably too late to review. If a reviewer finds a problem with code already in a system, there will be pressure to sweep that problem under the rug and move on, or to convince your that is not really a problem, or that quality doesn’t really matter, just this once.

The right answer is simple: use code review as a gate through which code must pass before it can become part of the mainline of the project. Use your source control system, and stack up proposed code changes that are nearly ready to go into the mainline. Then periodically perform your review process (whether it is in person, remote, synchronous, asynchronous, etc.). Once the code passes a final review process, then it goes in the mainline. If there are serious problems, the code sits in a branch, a developer improves it, and it tries again next time.

We have had excellent results with this approach, maintaining software quality for years on end even through ongoing development team turnover.


Three Critical Principles Of Developing Enterprise Software

Understanding, Workflow, Delivery. These three concepts sound trite, soundbites in technology for decades (substitute Execution for Workflow during the 1990s). It is hard to overstate the value of these key ideas and it is even harder to do a good job in making them a natural part of your team’s effort. They have many enemies:

  • Tyranny of the urgent

  • Laziness

  • Personal design preferences

  • Ego

  • Meetings

  • Distraction

  • Conflict

All of these can destroy an otherwise productive team. It is a leader’s job to manage these and protect the team from them. It is the individual team member’s responsibility to manage their own work and remove as much of this as possible. It takes everyone working diligently to work smarter for a project to succeed.


All too often we jump into projects thinking we understand what needs to happen only to find that we did not. At that point work has to be redone, time is lost and the customer is frustrated. Disciplining your team to dig in and fully understand a set of customer requirements is important. Please note that written requirements accompany but do not replace the understanding required to provide a solution. The written requirements are a tool to use but cannot replace the cognitive process of understanding.

When you start a new project, there is a natural limit because a customer will not tolerate an extended delay at the beginning of a project. You cannot charge blindly across the customer objection but you absolutely need to understand the problem domain at a deep level. This is a fine line that is difficult to walk. Using tools in a way that trap critical information is very important to achieving this balance. Have the customer provide videos of key staff performing their work function or using their current application. Customers will want you to be present and witness this, but resist. We have found it is critical to capture this in a way it can be watched over and over again by team members. Through this process real understanding can occur. Without it your team will find it difficult to remember a meeting six months prior and have trouble decoding the typed up notes neatly stored on their computers.

It can also be helpful to listen to customers talk about their vision for the project. Again, do not do this in a meeting but obtain a recording of this. New team members can hit the ground running after reviewing such valuable materials and the tools are readily available. This is not to say you cannot have meetings that supplement this information but all too often a meeting is all that occurs. It is commonplace for notes to be sparse from these meetings and our memories are notoriously faulty.

Once you capture this knowledge it is important to translate this into a set of requirements. Sometimes customers will give you these, but most of the time they are too busy and this falls on you. Follow through and process this into a detailed list of features that can be pushed into your workflow.


There are very few times that enterprise software will be simple, and any complex project can be derailed without a clear process for execution. There can be variations by organization, but I will speak generally of the process we use. Below you see a graphical representation of our workflow.


It is important for the project lead or architect to lay out a particular piece of work. Once it is ready it should go into a bucket where all the developers on a project can see the work that is staged. We often place these into milestones, sometimes referred to as sprints. Developers pick up the work and push the item through development, peer review, internal testing, and QA Testing.

The enemies I listed above mostly rear their heads to attack your workflow. There are always reasons that make sense at the time that lead to workflow destruction. A leader is responsible for guarding the gate. If any of these are allowed into the team and allowed to take root, there is a high likelihood of project cancellation, termination, and failure. Pushing items efficiently through a workflow allow for the most important part of a software project to occur: delivery.


From a customer’s perspective you have not really done much until they have software in their hands. Use the previous two efforts to both understand the core features and aggressively push them through your workflow. Use your understanding to plot the quickest path to putting software in customer hands for comment, feedback, and tactile success. Getting a project to that point is critical to its continued success. Completion of some limited functionality is far more valuable to your customer than partial completion of 100s of features. Shipping is golden, a lack of shipment is a recipe for disaster.

Why Choose Custom Software?

To meet the software needs of your business, there are two main paths:

  1. Buy software “off the shelf”
  2. Build custom software (in-house, or with a development firm)

In most cases, off-the-shelf makes the most sense, and it should be your default choice:

  • Acquiring and deploying off-the-shelf software is usually faster than getting custom software developed. Even complex installation and configuration it typically faster than developing new software.
  • Off-the-shelf software is generally cheaper than developing your own. The development cost of an off-the-shelf package is distributed among multiple firms, possibly many firms worldwide. These many customers more than offset the extra cost of mass production and distribution. Comparatively, with custom software your business alone bears most of the costs.
  • Off-the-shelf software typically has years of testing and years of production use, as well as feedback and improvement, giving confidence that it actually works.
  • Off-the-shelf software may include a money-back guarantee in case it does not meet your needs.

For all these reasons, the option of designing custom software bears the burden of proof in your decision-making process.

There are good reasons, though, to consider custom development, especially in mid-sized or large companies. Under the right circumstances, these advantages can make the decision to develop software the best choice.

Exactly the Software You Want

With off-the-shelf software you start with the features the vendor chose, and then perhaps try to persuade the vendor to add additional features. You may or may not convince the vendor that the features you want are worthwhile and in their interest. Moreover, the features may turn out to be a mirage:

  • The features might not actually work.
  • The features might work but still not meet your needs.
  • The features might interact with each other badly, even though they work in isolation.

Custom software, though, is almost infinitely adaptable to your needs. A custom development firm will develop the features you request, and will make them interact properly for your specific needs.

Top Notch Support

An off-the-shelf package typically offers some level of support. Virtually every vendor will claim to provide excellent support, but you will not know about the quality of the support until you need it. At that point, it is usually too late to undo your purchase decision, leaving you stuck with a frustrating shortage of real service. Your support contacts might lack knowledge of your problem domain, of your specific usage of the software, or might even lack good English skills. An off-the-shelf vendor’s highest tier of support may prove insufficient for software that you use to run your business.

With custom software, you can generally get in-depth support from the team who creates and maintains the software. Such a team can offer in-depth expertise, and the ability to not merely work-around problems, but also enhance the custom software on-demand to solve them.

Change Happens

The needs of your business are likely to change and expand. An off-the-shelf software package might leave you stuck with features that no longer work well, and require a “forklift upgrade” to move forward.

Custom software, though, can be continually enhanced to meet you growing needs, incrementally, so that users are never forced to violently switch to an entire new system.

Custom Software can be Cheaper!

Off-the-shelf software is cheaper most of the time, but not always! Occasionally, custom can be less expensive. How can this happen?

  • The best off-the-shelf package still requires a great deal of customization.
  • The best off-the-shelf package requires a great deal of changes to your business.
  • The off-the-shelf package with the features you need, is prohibitively priced for a higher market tier.

More than once, Oasis Digital has created custom software for our clients which solved their specific problem at a lower cost than their off-the-shelf options. In one such case, our client needed a highly flexible rules-based system for calculating their sales quotations and product configurations. This sort of function is typically available in large Enterprise Resource Planning (ERP) systems. The ERP systems they found with the required flexibility, were high-end packages aimed at large enterprises, with a price to match. But they did not need such a system, they needed only the specific features for sales quotations and product configurations. Oasis Digital’s custom solution met their needs at an attractive price.

To Get Different Results, Use Different Software

If you are running a for-profit business in a competitive industry, you have an added incentive to consider custom software. With off-the-shelf software, you will end up using the same software that your competitors are using. Why play on a level playing field when you can develop advantages that are unique to your way of doing business? If you have proprietary ideas or processes in your business, custom software can capture those processes, amplifying your ability to operate more effectively or efficiently than your competitors.

Create a Corporate Asset

Custom software becomes a corporate asset. This can benefit you in several ways.

  • In the event of a company sale, your custom software adds to your unique operating capabilities, potentially giving you leverage to ask for a higher price.
  • Alternatively, your custom software might become an asset you can re-sell to others in your industry.

Choose Wisely

Two pages later, the point at the start is still correct: prefer off-the-shelf software. But once you consider all the factors, custom software might be the right decision for you.

(This article is also available as a PDF download: CustomSoftwareFoolishOrBrilliant)

Slider Control for Touch-Screen Applications

At Oasis Digital we are working on an application that will run on a touch-screen computer, and which will be used to (among other things) control an audio amplification system. There are some design considerations for touch-screen applications which are rather stark once you use the touch-screen for a few minutes:

  • A finger is much less precise than a mouse pointer – hitting small targets is hard.
  • Drag/drop operations (or grab-adjust operations) sometimes don’t start quite where you aimed.
  • Your finger blocks the point on the screen where you are pressing.
  • The concept of keyboard “focus” is moot on applications with no keyboard.

To accommodate the first two of these, we coded a prototype/example of a slider control suitable to use for audio adjustment in such an application. It has these key features:

  1. It does not matter if you click on the “handle” or on the rest of the bar – because with touch screen you won’t be able to reliably do one vs. the other.
  2. The adjustment is not immediate; there is a limit of the speed of the adjustment to produce smoother audio control. The slider handle will move down very quickly, but will move up slowly. This avoids the possibility of an accidental touch pushing the audio amplification in to feedback.

The prototype/example looks like the screenshot here:

Touchscreen Slider

… but ignore the static image, it doesn’t tell the story. To see it in action, take a look at the screencast below (also available in a WMV file, easily viewable only on Windows) or download the example program (Windows) and play with it. The source is also on github.

This example is compiled in Delphi 2007. An enhanced version of it is in a production application for a touch-screen audio control system.