Running my own software company, I run into people trying to solve all kinds of different problems with software. As such, I end up using a variety of different technologies, languages, platforms, and frameworks. Recently, a client project required me to download MATLAB in order to experiment with several existing toolkits needed for the R&D phase of the project. The first thing I noticed was the price tag. Today, the overwhelming majority of development environments are free. However, MATLAB carries a hefty price tag of $800/year for commercial customers. After installing the application, I found out that the plugins (called toolboxes) averaged an additional $500/year. All told, this development environment was going to cost me around $3000/year after all necessary plugins were purchased.

Is It Worth It?

Seeing that MATLAB is so expensive, and so highly regarded by many in the research and academic community, I assumed that the MATLAB user experience was going to be epic! How wrong I was. The code I was examining contained dozens of files across numerous folders. Of course, this isn’t abnormal for any large project and I expect any decent IDE to be able to handle it. Any IDE except MATLAB. Need to find where a function is defined? Don’t expect any tools in MATLAB to accomplish that! Of course, you can do a find in files for all references of a string, but that’s not particularly helpful when a function is called dozens of times or has a short name. How about displaying a call hierarchy so that you can see where functions are being called? Nope – that’s not possible either. Ever aspect of the IDE proved to be well below what was commonly available in other IDEs.

If you’re not intersected in the user experience, I guess MATLAB is great. Apparently, its ability to perform all kinds of mathematical wizardry is beyond compare. It’s great for solving linear algebra problems and other advanced math tasks. Unfortunately, I wasn’t interested in that.

Open Source Code

I managed to find several open source projects and toolboxes for MATLAB. I was interested in understanding how these particular toolboxes work, so I started examining the code. MATLAB, like so many other languages, is a weakly-typed language. While weakly-typed languages do offer many benefits, readability is rarely one of them. MATLAB also does not require variables to be defined before use. This can be very difficult to follow particularly when the bulk of the code I saw contained neither useful variable names nor adequate comments to understand what’s going on. Very typical of people without a development background.


I was very disappointed with everything I saw in the MATLAB community. I assume most of the users are mathematicians and have no idea the kinds of features that are available in modern environments, so they have no idea what they’re missing. Likewise, I assume they’re used to digging through poorly documented code with variable names like g, f, c, and y. For me as a developer, this is neither acceptable nor maintainable long-term. For number crunching, I much prefer R. It may not have the most advanced IDE, but it doesn’t set me back anything either!

Debugging & Maintenance


Long after the initial fun of developing an application comes years of debugging and maintenance. Yet, many languages and developers fail to make choices that will ensure that future maintenance will be possible. Then, when problems occur, substantial time and effort is spent trying to resolve the issue.

Current Trends

It seems that right now, a growing number of developers and development teams are transitioning to languages like Python and Javascript. Both of these languages can do great things. Unfortunately, they both suffer from the same problem – they are incredibly hard to debug and maintain. Why is that? Python and Javascript are both weakly typed scripting languages. What does that mean? In short, it means that the programmer can be lazy about how they define things and let the computer do all the work. Unfortunately, it also means an increased risk of runtime errors and greater difficulty in finding problems.

Magic Frameworks

This is exacerbated by magic frameworks. Everyone loves Ruby on Rails and Django. But both become a nightmare to debug very quickly. Need to change something from the framework? Great – your hack will be the source of nightmares when you leave. While these frameworks may simplify our lives in the short term by providing a quicker time-to-market, in the long-term they are more difficult to maintain.

How Can We Fix This?

Unfortunately, I have rarely seen well documented Python or JavaScript code. Typically, users write code and forget about it. Online videos and tutorials rarely stress the importance of comments and documentation. Thus, we end up with fragile code nobody understands. As a developer community, we need to do a better job of passing on our knowledge of code to the next developer. This means comments, readme files, and other documentation. If you write software using weakly-typed scripting languages, you owe it to those who will debug your code later to put in the extra effort!

Agile Pricing?

Today, agile software development is the standard project management model. In many ways, it’s an excellent model. It allows for rapid changes to meet business needs, helps ensure quality throughout the process, and ensures that stakeholders have maximum visibility. But there’s one big problem…

How Do You Price Agile Projects?

Since Agile projects requirements are continually refined during the project, how do we know the amount of work to be done? How can we define a timeframe for development if we don’t have a clear picture of requirements? How can I tell you the cost when I don’t even know exactly what you want to do? Certainly I can provide an estimate based on the high-level definition of the project. But agile makes scope creep easy. New requirements can be added or old requirements removed. This means my best estimate may be wildly inaccurate.

How Can Developers Learn to Estimate Projects?

Making things more difficult, developers who have only ever worked in an agile environment will have difficulty estimating project workload. Why? Because they have never had to. Agile is so focused on the now that no attention is ever paid to the larger work of the project.

Future of Agile

The more agile work I do, the more I have mixed feelings about the process. While it allows greater management input throughout development, it suffers from a variety of problems. Sometimes, I even refer to it as (Fr)agile Development. This is just another issue to add to the list. My hope is that the software industry finds a better way to manage development that solves the problems with Agile while still providing all the positive aspects.

A Programmer’s Purpose

Today, it’s becoming increasingly popular for programers to be ‘opinionated’. In the software world, to be ‘opinionated’ means to believe your way is the right way. Other ways are wrong, and your way is right. There’s nothing wrong with having a preference, but the truth is that there is little room for opinion in software engineering. Software projects need to meet requirements such as budget, programmers available for maintenance, stability, etc. Championing a new language or framework may be fun, but when you leave, are there other developers available to support the project? Even if your preferred framework is better, it’s of no concern to a client when the language dies for lack of users and they have to pay to have the application rewritten.

A computer science student I know is all about Julia. Honestly, I’ve never met a single Julia developer or even seen a line of code in that language. On the list of popular languages, it’s not even a blip on the radar. However, this student insists that Julia is the way of the future. I’m not sure where he’s hoping to find work, but it won’t be in the local area. I remember the same thing when Scala came out. Every video I saw spent half their time attacking Java development. As above, I know absolutely no projects written Scala nor do I know any local companies either using it or planning to.

How should we select frameworks and languages?

The answer is actually pretty simple. Commercial software development has one purpose – to support some business use case. As such, frameworks must be chosen to support commercial business. What things make a language or framework commercially viable? It should be stable, have tools available to support commercial usage, and be widely used such that new developers can easily be found in the future. Additionally, it should have adequate resources available to help when you get stuck.

Commercial application development is no place for experimenting with new frameworks or basing your decision on an opinion about what is better. Find commercially viable frameworks and save yourself the hassle of supporting your new framework that may be dead in a year.  A programmer’s purpose it to write commercially viable software – period.

Microsoft AppCenter

Several years ago, I needed to find a way to distribute mobile applications to test users. Ideally, the solution should allow for anyone to access the test application. This would include internal users as well as key stakeholders within the client organization. The distribution channel should support Android apps as well as iOS and, optimally, any other application type I would like to deploy. After searching, I found HockeyApp. What an amazing tool HockeyApp was. Not only did it meet those requirements, but it also allowed for integration of their API to include advanced features. For years, I used HockeyApp without issue. Apps are built by my automated build platform, pushed to HockeyApp, and users are notified of new test versions.

Fast forward to today, and HockeyApp is now owned by Microsoft and being moved to AppCenter. To be honest, I’ve never been much of a Microsoft fan. I could point to countless reasons such as lack of good native development tools, poor support for scripting or automation, their hatred of Linux (even calling a cancer), Internet Explorer which worked differently from every other browser for developers, and now I can add their horrible transition to AppCenter to the list.

Today, I received a notification from Google that one of my apps was removed from the store. It appears to be a mistake on their end, but I need to verify and respond to Google. So, I uninstall the copy of the app from my phone and go to AppCenter to download the app onto my phone. The first thing I notice is that I have multiple copies of the app but none of them are tagged with the appropriate build type. I can’t tell free version from paid version or beta version or anything else – just a bunch of apps with the same name. After clicking on the individual versions, I find out that none of them are available for me to download. After digging around, it appears I need to release the app to a distribution group. It had been setup properly for years, but now it’s broken. So, I go to the website to check the distribution groups. Guess what? There is no way to change them in AppCenter. I can see that I have a few groups, but I can’t even tell who is in them. So, to fix the problem, I will need to go to every single app I have (a total of 28), add them to a new distribution group (with unknown members), and rerelease them (generating 28 emails to each member of an unknown distribution group). What a horrible experience for both me and my team members. As a small business owner, I don’t have the time to waste to make all the necessary changes, updates, reconfiguration of continuous development pipelines, etc. What an absolute nightmare.

Maybe my experience will be better once I get everything transitioned to AppCenter. Perhaps these are just short-term growing pains. Regardless, this is just another example of why developers have always been skeptical of Microsoft – and another reason I’m glad I use Bitbucket instead of GitHub.

Definition of Done

A few years ago, when the company I worked for at the time switched to agile development, I remember my boss saying how important it was to define ‘done’. I thought that sounded silly. Don’t we all know what done means? Do we really have to define it for the team? But as we discussed the idea, I realized it wasn’t as strange a question as it sounds. For instance, if I ask my wife if she’s done with the laundry, she might say she is. So, I assume that I can go to the closet and grab my favorite shirt. However, when I get there and don’t see it, I’m frustrated. Why did my wife tell me the laundry was done when it clearly wasn’t? Obviously, she and I had defined ‘done’ differently. To me, it means washed, folded, and put away. To my wife, it simply meant washed. We had both defined ‘done’ using a different criteria.

This same thing happens in software development. When we talk about software being done, we may mean that the development has been completed or that it’s been tested. Or, maybe we mean that it’s been deployed to a staging server or that it’s been through User Acceptance Testing. Maybe we mean that the source has been checked in to a branch or that it’s been merged to master. All of these things represent a drastically different definition of done.

As a customer of software services, you need to be able to define what you mean by done. If you don’t, you run the risk that your development team does not perform to your expectations since you were both defining the endgame differently.

Read the Fine Print

Yesterday, I was contacted by a customer who wanted to add push notifications to their mobile application. This is a common desire from customers, but they generally don’t have the infrastructure to support push notifications. Push notifications require a server to generate the notifications as well as some type of software to allow the user to create and send those notifications. Without any server infrastructure, smaller businesses are left without the ability to implement push notifications. Of course, there are a variety of services available for users to overcome this problem. One such service is OneSignal. OneSignal allows for very rapid implementation of push notifications using their servers and infrastructure. A developer can have everything setup and ready to demo in less than 15 minutes. Before suggesting this solution to the customer, I wanted to see pricing options and terms of service. But when I looked for pricing, I found it was completely free – there were no pay options. That sounded great, but I knew there had to be a catch – after all, businesses have to make money somewhere! As I read the Terms of Service, I was shocked to see:

Licensee acknowledges and agrees that the SDK enables Licensee to collect certain information from end users (“End Users”) of the SDK’s functionality (collectively, “SDK Information”), which generally helps provide developers with functionality to target and personalize the notifications they send to end users. This data collected includes: End Users’ mobile advertising identifiers, such as Apple IDFAs and Android Advertising identifiers; End Users’ email addresses End Users’ IP address, device push token, precise location (e.g., GPS-level) data, network information, language, time zone, product preferences, and privacy preferences.

So, this free service is collecting just about every piece of information possible about the user. While this may be ok for some apps, for many apps this would constitute a pretty substantial privacy invasion. Now, for my application, I would have to craft my own Terms of Service and ensure the user was aware that I was collecting the above information. In the tech community, do we read the terms of service, particularly when they will impact our end users, or do we just ignore them? In this instance, I am very glad I dug further. While I found OneSignal to be an awesome product, the terms of service are simply incompatible with the application I’m working to deploy.

Enthusiastic Indies

Several times each month, someone gives me an idea for an app. Usually, it’s an app they would love to have, and so they assume there must be a market for it. These apps typically fall in niche markets. For example, I have been asked to write apps to help firefighters identify symbols on chemical trucks, to aid frequent travelers in finding radio stations matching their musical taste, or apps to help off-roaders find their way and map new trails. Each of these ideas are great, but none of them would ever generate enough money to pay for development. The problem is that developing good mobile applications typically requires a fair amount of time for any non-trivial problem. And, since most users will look for free apps instead of paying for them, there’s little income generated from an app. Of course, there are some apps that make a substantial sum of money. Well known games, for instance, can generate massive amounts of revenue for their developers – but this is an incredibly small percentage of the apps out there.

So how do all the niche market apps get out there? Often, they are done by a devoted indie developer who is passionate about solving some problem. So, they develop an app. They may spend months learning how to write an app, or they may be a programmer writing an app for one of their own hobbies. Either way, they spend countless hours writing software that will likely never generate enough money to even pay for the electricity they used to write the app.  These developers are really an unsung hero of the tech age. Developers writing code for hobby projects create not only apps we use on our phones, but also countless free applications we use online, or on our desktop machines.

It’s amazing to me the amount of free software and applications that we have available to us because of passionate indie developers out there writing code for free. Few other professions give so much back to the community!

GameMaker Studio 2

For the last decade, I’ve been tinkering with game development. I’ve played around with DirectX and OpenGL, and written games for Android, as well as desktop games using Java and Unity. I’ve taught students to use Scratch and to write scripts in C# for Unity. Through the years, I’ve come to really like Unity. Unity is free, can create awesome 3D games, and has a wide variety of resources available through their resource store. However, I’ve found that there are some things that Unity just doesn’t work as well for. For instance, while Unity does have 2D support, it seems like a hack to their 3D world. Platformers can be especially painful since floating platforms, for example, violate the rules of physics. And while their animation tools work very well, they can be overwhelming for the novice to use. Overall, Unity has a steep learning curve and, too many times, things that would seem simple become painfully difficult. I remember the attempts I made at creating a simple 3D racing game – wow, dealing with their car controller was a lesson in frustration. This isn’t to say that Unity isn’t a great tool, it most certainly is. It just isn’t the best fit for all games. If I wanted to create a first-person, explorable, realistic, 3D world to explore – Unity would be my first choice. But for many other games, Unity just isn’t your optimal choice.

Enter GameMaker Studio 2. I was recently contacted by a non-programmer who had been tinkering with GameMaker Studio and wanted to know if I would help him make a game. Having worked so much with Unity, I was initially hesitant to switch platforms. To make matters worse, GameMaker Studio isn’t free. So, I reluctantly downloaded the demo version and played around. Wow! What an amazing development platform! I quickly upgraded to the full version ($100) and have been loving what I can do! One of my favorite aspects of GMS2 is the ability to create and edit sprites inside the app. This may seem trivial, but I don’t always want to use Photoshop or Illustrator to create simple pieces of graphics content. Another great feature is how the project resources are automatically broken down into types – objects, sprites, audio, etc. For many junior developers, project organization is never considered. Long term, that means projects become unmanageable. The simple aspect of automatically organizing resources by type helps to keep the project clean. The GMS scripting language is based on C++, but all the ‘hard stuff’ is hidden from the programmer. No need to worry about imports, constructors, or any of the stuff that would make programming daunting to the junior developer. Individual micro-scripts are created for startup, step (each new frame of the game), or events such as button or keyboard actions. These small scripts keep code small and more easily understood. (I would image that as a project gets larger, this could be problematic. But for smaller projects, this is nice.) GMS has built-in functions to change the angle of an object, play a sound, or create labels on the screen. Built-in variables exist for an object x/y position as well as the screen dimensions. Everywhere I look, I see that the makers of GMS worked to create a platform for non-developers to create games with as little technical knowhow as possible. For me, this is particularly exciting. Why? Because many of the people who want to work on a game don’t have the technical expertise to use a more complicated development environment. But with GMS, the bar has been lowered to allow everyone the fun of developing games!

If you’re interested in trying game development, I would highly recommend Game Maker Studio 2.

Successful Software Projects

Throughout my career as a software engineer, I have seen projects succeed while other projects failed. Some projects are delivered on time and under-budget, others are delivered late with costs substantially more than anticipated. What determines the success or failure of a project? Two simple things make all the difference in the world: requirements gathering and feedback.

During the early phase of a project, the requirements gathered will be used to determine a project’s timeline and the corresponding budget. However, rarely are initial requirements adequate to determine much more than a high-level understanding of the application. Often, things like user management requirements, reporting requirements, security requirements, and similar tasks are glossed over even though they are essential elements. Likewise, core pieces of functionality may not be well thought out by project management. A lack of consideration for all the permutations of options that may be present and how they impact each other or the application in general serve as an example of this. In an eagerness to get the project moving forward, holes are left that must be filled in later. Unfortunately, with such incomplete data it’s impossible to determine a budget or a timeline. Nonetheless, timelines are provided based on guesses that turn out later to be way off. As the deadline approaches, developers are forced to take shortcuts that create long-term problems. This can be resolved by spending a little extra time gathering requirements early so that the true scope of an application can be determined and more accurate timeframes can be provided.

The second key to a successful project is frequent feedback.  As a project progresses, it is imperative for managers, users, and other stakeholders to have visibility into the application so that they can verify functionality, critique the user experience, and provide other necessary feedback to ensure that development teams aren’t headed in the wrong direction. While requirements gathering goes a long way to ensuring that developers go down the right path, feedback throughout the process enable problems to be addressed quickly before substantial development effort is wasted. This kind of visibility has the added benefit of allowing management to see where a project is and to begin developing advertising material or documentation.

If you want your projects to be successful, put in a little extra effort upfront to provide adequate documentation and ensure that you provide feedback to development teams throughout the process. Not only will you appreciate the effort, but your developers will too!