The Importance of Engineering

Battleship

During my career, I have encountered projects that were well written and those that were not. Often times, the poorly written projects were farmed out to development firms in under-developed parts of the world such as India or Pakistan. What is it that makes code poorly written? For me, the most important aspect of well written code is maintainability. No other metric is as easily correlated to long-term revenue and cost as maintainability. Code written today should be able to be quickly modified in the future when bugs are found, when requirements change, or when new features are desired. How can this be accomplished? First, projects need to be logically laid out. Code packaging schemes are necessary to easily navigate large projects. Throwing everything in a single folder will ensure that future developers have a more difficult time finding code they are looking for. Second, files and classes must be named logically — otherwise, every file becomes ‘mystery meat’ that is only identifiable when it’s opened. Third, classes should broken up appropriately. I have worked with projects were there was only a single data access object for the entire schema. Monolithic files such as this are substantially more difficult to navigate, and they can also cause problems with source control if multiple developers are trying to edit different parts of the file. Fourth, consistent style should be followed and whitespace should be cleaned up. Following code with different styles, or with 10 lines of whitespace in the middle is more difficult. Imaging reading a paragraph in a book where the author decided to add 10 extra blank lines — code is no different, it is intended to be read. Fifth, properly breaking out functions is imperative. Too often I have seen code were, for example, the code to send an email was entirely replicated over and over again instead of placed in a single function. When email standards change (for example, changes to security) or when the tools you use to send email change (such as switching from SMTP to a REST based service such as MailGun), you can be sure that the time taken with a poorly engineered codebase will be longer and that you are more likely to have a greater number of bugs. These are some of the biggest issues I typically encounter in project after project and they cause a significant problem to businesses. Unfortunately, the customer is often unaware of how poorly the code is written. When they hire someone else to maintain the code, they wonder why it takes so long to update or why there are so many bugs. They falsely believe the new developer is less competent and attribute the problems to him or her. Long term, time-to-market suffers, customer confidence is diminished from bugs, and business opportunities are missed because of wasted time. When you hire developers — particularly when they are outsourced — it is imperative to ensure that they are writing good code. Ask to see code samples before hiring, perform frequent code-reviews with them, and specify coding standards they must follow. If you don’t, the money you save by using offshore resources will be lost during the course of maintaining the application.

Build Automation with iOS

I am a big fan of build automation. As a developer, the last thing I want to waste my time doing is compiling and distributing my software. Countless technologies are available that can play a part in automating your build process. Tools like Make, Ant, Maven, and Gradle can define the steps required to build the software. JUnit can be used for unit testing, and plugins like Findbugs and Checkstyle can be used to check code quality. Then, HockeyApp can be used to distribute apps to test users (or even end users). All of these processes can be executed automatically by a tool like Jenkins. Jenkins is an amazingly powerful tool that pulls all the above together in a nice web-interface with countless plugins available to accomplish just about any development task. So long as your project can be build using command line tools, Jenkins can build it for you. Unfortunately, there is one exception that really sticks out — iOS. Sure, you can build an iOS application using Jenkins, but you will find that you spend nearly as much time managing a failed build process as you would spend manually building and deploying the app yourself. I have dozens and dozens of tasks that I have automated with Jenkins – Android builds, JBoss applications, C apps, scripts, REST calls, and iOS builds. The only processes that ever requires my attention are the iOS builds. Why is iOS build automation so painful? Well, once you try it you realize very quickly that Apple does not intend for you to use anything but the Xcode environment for development. Switching profiles, certificates, etc require all kinds of ruby scripts and a detailed knowledge of the iOS build process. There is no simple ‘make’ command you can run to build the application. Certificates cause all kind of problems too. New developer on the team? Great – plan on the build breaking when he checks in the project with a new certificate you don’t have on the build server. New hardware to test against? Don’t plan on using any of the existing builds — they won’t work until you add the device to your profile and install new certificates. Time to pay your annual fee as an Apple developer? Be ready to install new certificates on Jenkins. Sure you can try to automate some of the certificate mayhem, but plan to enter all of your Apple developer passwords, keychain passwords, and any other password or key you can imagine into Jenkins to try to accomplish the build. Then, when it comes time to deploy to quality assurance staff or test users in your organization, plan for a whole new round of fun. Apple really doesn’t want you using anything but their TestFlight tools. I could go on, but you get the point — iOS + build automation = pain. I love Apple’s line of laptops, which are a dream for developers. I just wish their iOS platform wasn’t such a nightmare to work with.

The Value of Education

Anybody who knows me knows well that I value education. I have studied countless languages, formally trained in both locksmithing and herbal medicine, achieved a third degree black belt in taekwondo, and earned an associates degree in psychology. But what surprises most people is that I don’t have a degree in computer science. In fact, even the degree I do have was earned through a correspondence school less than 10 years ago. I did not go to college out of high school, I joined the army. And, just about everything I know about programming I taught myself. Why does this matter? Well, in today’s society there still seems to be a strong desire for candidates applying for programming positions to have a bachelors degree in computer science. Many job listing require a bachelors at a minimum. The unfortunate thing is that most of the best programmers I have ever encountered did not have a degree in computer science and many had no degree at all. Throughout my career, I have always been identified as among the best when it came time for reviews — so a degree is not necessary for someone to ascend to the top of the class. So what is needed? Programming is an art that is learned through doing — not through formal education. And that is where the problem begins. I have interviewed countless candidates for programming positions with degrees and, sadly, few of them really knew the first thing about programming. They had attended years of college, but couldn’t identify the objects in a problem or design a trivial database to house the corresponding data. Why? Because they had never actually programmed much of anything. Maybe they implemented a stack, a linked list, or a sorting algorithm. And, while an understanding of those things is important, they already exist in the libraries of every language out there. Have they ever written anything more than that? Typically, I hear graduates tell me about one or two projects they worked on. They have a degree, but they’ve only ever written one or two real programs. What’s the value to that? Their piece of paper has come with no actual knowledge or expertise. We seriously need to revamp our education system to focus on real world training and spend less time on the things which bring no value to the business world. If we do not, we will continue to watch computer-related jobs go to foreign firms that are better trained and cheaper than our own fellow Americans.

Writing on the Wall

In the 90’s, an amazing thing happened – Linux was born. This small project has had a profound impact on the world of technology. Not only did it create a Unix clone, it advanced the open source movement by leaps and bounds. During the decade after the creation of Linux, companies, like Microsoft, would argue against the idea of open source and attack Linux. But then, in the early 2000’s, things started to change for the Linux movement from an unlikely source – Apple. The new Mac OS X would use BSD (an operating system very similar to Linux) as the core of the operating system. The Linux world was very excited about this! The change meant that Unix/Linux hackers had support for Unix on a commercial operating system. Now, it seems that developers across the globe are using Macs for development. Why? Because services like Google Cloud and AWS, as well as Docker, use Linux. Mac users can develop cloud applications on their machine to be deployed to Linux servers and have similar environments on both. Where does Windows come into the picture? Microsoft has fought against these technologies, and has even come up with their own competing cloud service – Azure. But, as more and more developers jump ship to Linux or Mac, Windows needs to move. And over the last several years they have. Microsoft’s .NET Core is not only open source, but it also runs cross-platform – an idea that seems almost blasphemous to the Microsoft of a decade ago. And, as of last fall, Windows 10 includes the option to install Bash support on Windows. Indeed, it would appear that Microsoft has seen the writing on the wall and is working to change the direction of their company to be more friendly to the Unix world that has secretly been in control of computing since the dawn of technology. But is it too little too late? Can Microsoft lure developers back with a Bash shell? Time will tell. But, as for this Unix user, I’m glad to see the change.