Posts

Posted on

Killer Robots

During the last year, countless tech leaders have talked about the danger that artificial intelligence could pose in the future. Like most people, I laughed at them. After all, do I really think that The Terminator or The Matrix were prophetic? Hardly. But the more I read and the more I pondered it myself, the more concerned I became. Now, I wonder if there’s any way to prevent it from happening at all.

Is it really reasonable to think AI could take over the world? Do we really think code will be so poorly written and that software testers will be so incompetent as to let AI robots kill humanity? Unfortunately, I do. Not intentionally, of course, but bad code that wasn’t properly tested will make it into the wild on robots. Consider all the system updates that have been performed on your computer or your cell phone. Think about all the app updates that happen every single day. Consider all the one star reviews for apps on the mobile stores. AI will be no different.

Consider all the potential causes of AI issues. Developer errors, inadequate testing, corporate release requirements, poorly defined ethics, unforeseen events, etc. Each one of these issues could cause AI to perform in ways it was not intended with potentially catastrophic consequences. Consider government AI being developed by the lowest bidder – wow, that’s scary.

The more I think about that, the more certain I become that AI will eventually cause huge problems to the world. As such, it’s imperative that we – the tech community – consider the limits of AI – not in regards to technology, but rather in regards to safety and security. Do we want AI police officers or soldiers? That sounds dangerous. Could Russian hackers embed “Order 66” into our own robot army? Do we trust robots with firearms to make the appropriate decision in a life-or-death situation?

My intent is not to sound like an alarmist, but rather to begin thinking about the issues now. If not, we may find it’s too late to do so later.

Posted on

How I Got Here

During the last decade, I have been asked countless times how I would recommend someone get into the programming world without going to college. Many people don’t want to spend the time or money getting a computer science degree, and since I did it people generally assume I can tell them the shortcut to achieve the same in their life. Unfortunately, few people really realize the amount of time and effort it took for me to get where I am or the difficulties I’ve encountered by not having a degree in a field where a degree is expected.

I didn’t start working with computers until around 1997. I was in the US Army at the time, and worked exclusively with Unix machines. Unlike the Windows world, the Unix world has always had tools for developers. The machines I worked on had C, C++, Perl, Tcl/TK, Fortran, Bourne Shell, and numerous other programming tools. During the course of my work, I often used scripts written by others, and soon learned to modify them to do what I wanted them to do. I purchased programming books from Amazon and decided to learn more. At home, I setup an old computer to run Linux so I could have a similar development environment to the machines at work. As time went on, I decided to take courses through the National Cryptologic School on Perl, Unix Administration, C Programming, and other tech subjects. After becoming pretty comfortable with C, I decided to further my education through a correspondence school (the now defunct National Radio Institute) where I earned a diploma in Visual Basic Programming (as I was already pretty comfortable in C, I figured it best to branch out and learn a new language). A few years later, I took a few courses from the University of Maryland in C++ programming. Throughout this time, I spent countless hours at home learning everything I could about programming. I wrote programs to do all kinds of things – from GUI development to command line scripts. This was a difficult time in my life – working a full time job while spending all my free time learning to write computer software took a heavy toll on my marriage. But it would all be worth it when I got out of the Army and found a job in the software realm.

Then, in 2001, it was finally time to step out and find a programming job. Of course, I had no real experience as a programmer. I had written some code and scripts in the Army, but hardly anything that would really be considered production code. None-the-less, I managed to find a local company that needed an entry level programmer. And, thanks to a friend who knew the owner, I was offered a position. In my hubris, I assumed I knew everything at that point in my career. It would take years to fill the gaps in my knowledge to become a good programmer. With project after project under my belt, I would finally become a respected developer around a decade later.

What has my lack of degree caused me? During my entire career, I have found countless companies that wouldn’t even talk to me because I didn’t have a degree – they were unwavering on their requirements for a BS in Comp Sci even though I had been working in the field for years. At various companies I worked at, it became obvious that I would never be promoted simply because I didn’t have a piece of paper. Even though I could code better than my peers, my lack of degree held me back.

At no point has my path been easy. It’s involved an incredible amount of work and sacrifice. And if you’re thinking of teaching yourself to program and find a job, I wish you the best of luck as you are about to find out that it takes far more than watching a few online videos and making a webpage.

If you do choose this path, how can you make it successful? Passion – you must have an unwavering passion to write code. You need to spend every waking hour writing code, reading books, watching videos, and doing everything you can to become a good programmer. Expect to put in substantial time and effort. Expect to struggle finding your first job. Expect difficulty advancing in your career. Don’t think for a minute that it’ll be easy – I can promise you, it won’t.

Posted on

Change is Good

Yesterday, I took the Myers–Briggs personality test online. I’ve done this many times in the past, and I always come up INTJ – “The Architect”. This is a great personality type to be – listed as being imaginative and strategic, independent and decisive, hard working and determined, and having high self confidence. But as I began my journey into entrepreneurship, I realized that being an introvert wasn’t such a great idea. So, I decided to work to change myself to be more extraverted. After all, if I can’t comfortably talk to people and sell my services to clients, it’s going to be difficult to run my own small business selling software services. To make this change, I started reading books a year ago on small talk, communicating in social settings, and similar skills needed to be an extravert. I also read books on sales and leadership. After all, being an extravert isn’t going to get me far if I can’t sell myself or if I can’t project myself as being a leader in both business and software development. So, when I took the personality test yesterday, I was pleased to see that I have changed to ENFJ. Not only have I become more extraverted, but I have learned to rely more on my feelings instead of just logic. As a software engineer, that’s tough, but the world of people is rarely a world of logic – it’s a world of feelings. If you can’t relate to someone on that level, logic won’t get you very far.  Now, instead of being “The Architect” I’m “The Protagonist”.

Are you growing and changing? Is You 2.0 going to be better than you are today? What are you doing to get where you’re going? Are you willing to work to change the most basic elements of your own self to move your life in the direction you want?

Posted on

Social Networking

On Tuesday, my daughter and I embarked on an epic rail journey from Anaheim, California to Altoona, Pennsylvania. As I write this, I’m sitting in the lounge at the Chicago Amtrak station. Tomorrow, after another two trains, I’ll finally arrive home.

Anybody who knows me knows I love to travel by rail. While air travel is fast, it’s rarely fun. Rail is the opposite – much slower, but generally an enjoyable experience. One of the best parts of the train is the dining car. Not only is the food good, but due to the limited seating, you end up sitting with strangers. This is always a great way for real social networking. Tuesday night, my daughter and I sat with a couple retired from John Deere. He worked in the factory, and she spent years working in HR and in training other divisions. She was also a frequent traveler to Europe. The next day, I shared a meal with an outspoken Trump supporter and handwriting analysis export, a rail advocate and teacher, and a man who inherited land in the deserts of California. This morning, I shared breakfast with a pastor and his wife from Minnesota who work with troubled inner-city kids.

Unlike Facebook, Twitter, and other so-called ‘social network’ sites, riding the rails gives me an opportunity to share a meal with people across the country. People who are from different states, with different political views, different religious views, and every other difference imaginable. And, unlike social networking sites, discussions are typically cordial and enjoyable. I get to interact with people as people – not as a digital persona. I get to see them as a human – not as a highly curated avatar. These experiences are what real social networking should be about – not an anti-social experience behind a computer screen.

Today, instead of interacting with people on a computer, why not invite a friend for coffee, have dinner with your neighbor, or invite a coworker over for a burger. You’ll find the social interaction far more rewarding than Facebook.

Posted on

Picking a Server Platform

Many small businesses want websites or mobile applications that require server-side functionality. Often, this functionality includes a database to store user information. What options exist for a user? What are the pros and cons for each one? I will examine three different frameworks – Node and SQLite3, PHP and MySQL, and Tomcat. These represent just a small number of options available to a business – from small scale applications to enterprise solutions.

For small applications, I like Node and SQLite. Node is a simple platform to run server-side programming. Since it requires virtually no infrastructure, Node services can be installed and deployed in minutes.  Likewise, SQLite requires no installation. SQLite databases are a simple file that can be easily backed up or restored by copying the database file. While this framework is great for small applications, enterprise applications would benefit from more robust environments. Node and SQLite can work really well for small internal applications or to implement a small number of services using a small database.

Next up, PHP and MySQL. This combo is widely deployed on a variety of platforms. In fact, that’s one of the reasons I like it. Typically, service providers like GoDaddy have support for PHP and MySQL out of the box, so applications and services can be deployed without much effort.  PHP/MySQL is also more robust than Node/SQLite. On the negative side, PHP has a variety of versions that are substantially different and PHP code can easily become unmanageable if developers aren’t careful.  I like this solution for smaller customers needing a small number of services on an existing PHP server.

Finally, there’s Tomcat. This option is an excellent Java-based server bringing all the advantages of the Java programming language into a robust server environment. Tomcat can integrate with any database, but MySQL is a common solution. Tomcat is an excellent option for Java web applications or services, but suffers from one big problem – it’s the most complicated option to setup.  This option is best when a large number of users or a large database must be supported. This is the option I like to recommend for enterprise customers.

Numerous other databases and server platforms exist. Microsoft’s .NET platform can work great for customers who prefer Microsoft products and Ruby may be a desirable option for some customers too. As with all technology choices, server platforms must be selected based on customer requirements. Small customers appreciate rapid, low cost development while larger customers will want more robust solutions while being less price sensitive.

Posted on

Software as an Iterative Process

The world can broadly be divided into the physical world and the digital world.

In the physical world, products are manufactured and deployed. Those products never again see the manufacturer. If there is a problem, a new process may be implemented to solve the problem; but customers with the existing product will not likely see the benefit of the new process.

In the digital world, products are created and deployed just like in the physical world. However, everything that follows is different. When software problems are identified, patches are created or new versions are deployed. When the customer accesses the patches or upgrades their software, they see the benefit of the new changes.

This difference allows for a vastly different approach to creating and deploying products in the digital world. Unlike physical products, software can benefit from an iterative process. Software can be modified today, tested tomorrow, and deployed the following day. What if it doesn’t work? The changes can be rolled back or a new patch can be deployed. Unlike a physical product, a digital product is never complete.

This huge paradigm difference means that software companies can be far more nimble than manufacturing companies. Since changes can be made at any time, software companies enjoy far less risk than manufacturing companies.

As a developer of custom software, I often work with customers that are uncomfortable with this process. These customers want to wait until all functionality is present or until everything is fully polished and tested. This makes sense in the physical world, but can actually be detrimental in the software world.

Why is it important to use an iterative approach to software development? Since deploying software can be done quickly and changes can be rapidly fixed if necessary, frequent software releases allow customers to receive updates more quickly than if they waited for a major release. This allows customers to provide feedback if the features are not useful or if they work improperly. This feedback creates a loop that allows developers to go back and ‘get it right’ if they need to in a more controlled environment. Without this loop, it’s possible to spend months developing features that don’t actually meet user requirements or to create bugs that require substantial cost to find and rectify. This means wasted development time as well as missed opportunity costs. Additionally, small frequent software updates means that each individual update can be tested independent of other changes and issues are kept much smaller than in large updates. Frequent software updates also means a decreased time-to-market with new features.

Iterative approaches to software improve user experience, improve time-to-market, decrease difficult to find bugs, and shorten and simplify test cycles. Are you frequently releasing software updates, or are you treating software like it’s a physical commodity?

Posted on

Business Ownership

I started my own business about 5 years ago just to make Android apps for the play store. It was never really intended to become a full-time thing, just a hobby. Then, over the next few years, I started being asked to develop Android software for local businesses. Working full-time while running a growing business on the side was a challenge. Then, as my business continued to grow, I realized that I could no longer do both. I had to quit my day job if I wanted my business to continue growing. Of all the things I’ve ever done, that may have been one of the scariest and most difficult decisions I’ve ever made.

Now, after running my business full-time for the past three months, I wonder what took me so long. Every single day I wake up excited for the day. I get to choose what I’m working on today, when I go to work, where I will work from, and how long my lunch break is. I have the freedom to take complete control of my life. Sure, it’s scary at times, but it’s absolutely worth it. My friends look to me with awe – as though I’ve done something special. The truth is, I haven’t – I just did what millions of other Americans have done and said goodbye to the traditional job.

Have you ever considered starting your own business? If not, what’s holding you back? In another decade, will you look back and wonder ‘what if’? For me, I know that even if my business were to ultimately fail, I will never regret the choice I made to give it a try!

Posted on

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.

Posted on

Language Overload

As a technology enthusiast, I live in a great time. Computing devices are everywhere, artificial intelligence is advancing by leaps and bounds, and hardware platforms such as Arduino and Raspberry Pi have made it easier for people to tinker with new technologies without spending a lot of money. But with all the great advances in technology, there is one advance I do not enjoy – the endless list of new programming languages released every single year. I’m not opposed to new languages, they are a necessary part of the march of progress. But don’t we have enough already? One example is the proliferation of languages that operate on the Java Virtual Machine. Originally just Java, now we have Scala, Groovy, and Kotlin too. And, each one has their own group of advocates saying their language is the best.

When Apple announced a few years back that they were replacing Objective-C, I was originally optimistic. Objective-C is pretty much unused outside the Mac world. If you wanted to write iOS applications, you had to learn an otherwise useless language. Was Mac going to lower the bar for new developers and allow them to use a language that was already widely used? Nope – they invented another language – Swift. I’ve heard lots of great things about Swift, but I’m not really interested in learning another niche language to develop for a single platform. (Instead, I’ve chosen to use hybrid tools such as Cordova and Ionic).

What’s the harm in all these languages? While different languages do bring different things to the table, there has to come a point where the market is over saturated. With all the languages out there, developers have to pick which ones to learn and which to skip. While every developer should be competent in more than one language, it’s certainly not realistic to expect a developer to be an expert in a dozen different languages. And since every language needs their own libraries of code, scores of developers are wasting their time writing standard functions for another language. Solving a problem that has already been solved a dozen times in the past – with a new language – is not particularly useful.

Where do we go from here? I suspect that we will continue to see the proliferation of languages. Long term, we will see languages transition to legacy code far sooner than previously. This will make it increasingly difficult for companies to maintain their codebase and will mean more frequent rewrites of software applications just to stay current. For companies, I would suggest ensuring that the languages you choose are solid, stable, mature, and likely to be around long term. You can go for the newest language out there, but you’ll struggle to find developers now and you’ll likely end up having an ever more difficult time maintaining the application long-term.

Posted on

Loosely Coupled Systems

One of the principles of modern engineering is to create loosely coupled systems. But what does that mean and why is it so important?

In the past, it was common to create huge systems that included code for a wide variety of different functions. For example, an eCommerce system may include code for accessing the database, processing credit card payments, and interacting with an inventory management system. While having all the code in one place may sound great, it has some serious drawbacks. For example, maintenance becomes increasingly difficult the larger an application becomes. Additionally, testing must include the entire system, and deployment is an all or nothing deal. Upgrades are also more difficult as the entire system must be upgraded at once and opportunities for regression errors multiply.

Today, systems strive to be modular and loosely coupled. One piece may do credit card processing, another service may provide database access, and still another service may provide email support. While there are more pieces, these pieces can be assembled into a wide variety of configurations across different applications and these modules can be more easily tested. Once the credit card service is deployed, for example, it does not need to be changed or tested again until new features are required or bugs are found. Each piece can use the best technology for the task, and upgrades can happen on a per-service basis.

Currently, these services are often deployed as JSON-based REST services. These types of services are now becoming ubiquitous. A large variety of publicly available services are available for things like weather data, stock quotes, ISO country codes, etc.  This modular approach not only decreases development effort, it improves application stability as well.

On any project you’re involved in, whether it’s in writing the code or managing the project, modularity and loose coupling should be one of the most important guiding principles.

Proudly powered by WordPress