Today, I have upgraded my blog to use WordPress. Woohoo! Up till this point, I had been using the built-in blog plugin for RapidWeaver. It works nice, but WordPress will help me take my blogging to the next level. Most importantly, I can now blog from anywhere instead of just my home machine. The bad news? Links I have tweeted or posted on my LinkedIn page are now broken. So, I’ll be working to fix that and to make the style between my main site and my blog look more… well… consistent.
At a recent chamber of commerce meeting, a fellow member asked me what my company does. I replied that I create custom software solutions for businesses. He was incredulous that people actually paid for custom software. Sadly, this wasn’t a small business that might struggle to see the benefit of custom software — this was a large, well-established local business. Exactly the kind of customer that has much to gain from custom software development. But what do businesses stand to gain from custom software development? First and foremost, custom software allows the organization to have tailor-made solutions to their problems. Software is not a one-size-fits-all solution. The application that works great for a small business may not be flexible enough for a large business. Conversely, an application that works great for a large business may be needlessly complex for a smaller business. Even more importantly, off-the-shelf solutions don’t take into account the things that make a business unique. After all, doesn’t every business have something that makes them special? Maybe your organization makes custom products — how do you quote the product? Maybe your organization is an innovator in your market space — how do you implement process to aid in that innovation? Whatever it may be, your company is like no other — and custom software solutions can aid you in exploiting the things that set you apart from the competition. Second, off-the-shelf software may be updated or changed in the future in ways that break functionality you depend on. Remember the last time you updated Windows? Did everything go smoothly? Off-the-shelf software is the same thing — maybe it works great, maybe not. But as a business, is that a risk you’re willing to take? Custom software can mitigate that risk since you — the customer — are in control of any new features in the application. Furthermore, you can have the software modified to ensure compliance with new laws, new processes, or new requirements of any kind. Try having off-the-shelf software updated to meet your new requirements. Third, custom software can be written to integrate with your other systems. Integration of systems can ensure that data is not required to be entered multiple times, it can enable faster processing of information, and it can greatly improve operational efficiency. Custom software can be written to read inventory from your existing inventory control system, update employee data in your employee management systems, integrate with your customer management systems, or interface with any other systems your company depends on. Off-the-shelf software simply can’t compete with that. Fourth, custom software can be supported by the developers who wrote it — developers you have interfaced with, developers who understand your business and what makes it unique. Off-the-shelf support may or (more likely) may not meet your needs as an organization. Late on a Friday night, do you want to call a foreign call center for your software and hope someone can help or would you rather call the local software company and have them stop by tonight to diagnose and solve the problem?
As a software engineer for nearly 20 years, I can site countless samples of work I’ve done that has improved an organizations revenue, improved workflows, aided in reporting data to senior management, and ultimately aided the organization in increasing market share. And isn’t that exactly what businesses want? To increase market share? Why a company would not want custom software is a better question!
The IT world is full of certifications. When I started in the tech world, CompTIA’s A+ certification was the standard for computer techs and the Microsoft’s MCSE certification showed you were a master of the Windows system admin world. Today, the IT world has numerous certifications available to indicate proficiency in networking, system administration, hardware, security, application proficiency, and so forth. The world also has numerous programming certifications now too. Two of the more well known certifications include Microsoft’s MCSD and Oracle’s Java certifications. But are they as useful A+, MCSE, CEH, or other certifications? I personally don’t think so. In all my days as a software engineer I have never once interviewed a single developer who had any programming certification. I have never had a fellow developer tell me about passing the newest version of a developer certification. I have never been asked by anyone if I’m certified in a programming language. It has literally never once mattered. In the past, I had considered seeking certification as a Java developer. Then I saw the sample test questions. My first thought? If I ever saw this kind of code in real life I would do everything in my power to ensure that the author was immediately fired. The questions test your ability to remember esoteric language rules — not things I want to ever see used in production systems. Many of the questions ask “what is the output of the below code” and provide a code snippet. If you have to ask what the output of a complex code fragment is, you probably wrote it poorly. If I really needed to know, I’d copy the code and run it. None of this is really of any value. So, your brain is a human code compiler — that’s great. But the real questions remain unanswered — do you understand design patterns? Can you decompose complex problems in to proper object models? Can you write maintainable code? Do you have good coding style? Do you document your code? Do you understand networks and databases? When I interview a developer, these are the questions I need answered — not what the output of a horribly convoluted nested loop is.
This past week, I vacationed with my family in Disney World. It’s a favorite vacation spot for my family. While I was there, I constantly saw people looking at Facebook, Instagram, and other social media forums. The problem? They were completely ignoring the very people they were vacationing with. I assume most people go on vacation with their family or friends because they enjoy spending time with them. Sadly, that was not demonstrated by the people I saw. In one example, I saw a couple both looking at Facebook while their young children pleaded to be lifted up so they could ring the bell that was just overhead. Their parents never heard them. The children tried lifting each other up to no avail. Then, the line moved forward and the opportunity was lost. Over and over again, while at dinner or in line for a ride, I saw entire families too interested in what people they barely know were doing to pay attention to the people they love. I once heard it said that social media should be renamed anti-social media. Sadly, I agree. All to often our social media habits actually prevent us from engaging in real social behavior and instead we focus on a virtual world – a highly curated reality where everyone’s life is picture perfect and utterly fake. We take selfies to show everyone our life is awesome too. Yet, the reality is, it’s all hollow and meaningless. While we’re trying to impress someone we knew in high school, the people we actually love are sitting on the sidelines of our life. Shut off the phone — spend actual time with the people that matter instead of wasting your watching what everyone else is doing.
I frequently talk to parents as well as people in the educational community about what language kids should learn. Maybe they remember their uncle talking about Fortran, or they have a relative that uses Python – but they want to know what their children or students should be learning today. It’s a great question as the world of computer programming is always changing. The last 20 years has seen countless languages gain widespread usage — and I’m sure that’s not going to change anytime soon. Unfortunately, not everyone is up-to-date with their computer programs. Just a few years ago, a child where I was attending church asked if he could job shadow me for an assignment in his computer programming class. Always wanting to encourage young people to pursue technology, I was happy to oblige. When he came go my office, the first question I asked was what language he was learning. He gleefully responded: “COBOL!”. This was just a few years ago, and a student was being taught COBOL? I asked what else he was learning, and he said they were learning RPG and SQL. Wow. The only thing useful there is SQL – COBOL and RPG are long dead. But even SQL isn’t necessarily useful on its own as it’s not really a programming language, but a language for accessing data. So, what would I recommend people learn today? Well, a friend showed me a great website to help someone pick a language based on their interests – Best Programming Language For Me. The languages provided are modern, useful languages and their selections reflect the best choices for someone new to the art. Another great resource is the IEEE 2017 Top Programming Languages. Either of these sites can help you pick a language with a future – unlike learning COBOL today.
Today, I was onsite at a customer location. This particular customer has an interest in programming, and showed me a site he was checking out that asked a variety of questions to determine what language he should learn. Do you want to write games, web apps, desktop apps, etc. For nearly every sequence of answers, I could predict what language they would pick. Why? Because I have used countless languages over the years and know where each one excels. Another customer recently asked me to create a very trivial service that would consume JSON messages sent from a server. You could write a Java app for this, but why? My suggestion was either a simple PHP script or a Python app running a REST service with Flask. Either option is far simpler than writing Java code to handle the processing. One of the key indicators of a developer’s maturity is their ability to pick the proper technology for the problem at hand. For the customer, the technologies selected can make a huge difference not only in the price of the software, but in it’s success as well. This extends beyond programming languages. Mature developers understand build systems, revision control systems, project management methods, design patterns, and so much more. For customers, picking an inexperienced developer can mean substantially higher development cost, increased long-term cost of ownership, increased development times, and numerous other problems. An experienced developer can help you navigate the technology map and select the best options in order to provide the best user experience at the best cost.
Agile development seems to be the ‘in’ thing for software development firms today. Everyone has their daily standup meeting, scrum masters, sprints, and so forth. But does it really bring any true value to software development? I don’t think so. In fact, I have taken to calling it fragile development. Why would I say that about such a beloved idea? Because my experience is that it creates horrible software. Sprint after sprint, developers work to output code often without knowing the big picture. Day after day, short-sighted development goals are pushed so you get enough points done and complete everything for the sprint. Managers now have even more ability to micromanage since everything has to be done at the end of the sprint and everyone has to report in with their daily progress. Time is wasted in meeting after meeting that brings little if any actual value to the team. What does all this mean? It means that developers are always under the gun to output code quickly so it’s done for this sprint. This causes developers to take the short path instead of analyzing things more thoroughly since such analysis would take more than the allotted points and may push things off schedule. Developers are never able to try new things because failure is not an option — points must get done and software must be pushed. Software engineers never have an opportunity to practice engineering skills or architect larger systems because everything is broken down into bite-sized pieces without any real worry about how it all fits together. To make it worse, important technological changes and refactoring get pushed to the bottom of the list since they do not have an immediately visible benefit for the organization. In the end, developers never grow or develop, code stagnates, and poor software becomes the norm. Sprint after sprint turns into a death march for features, bugs never get fixed (unless they bring immediate business value), and the expertise of senior developers is ignored in favor of short-sighted business objectives. If you want quality software, leave engineers do what they do, give them the latitude to make the necessary decisions to create the product you want. Qualified engineers are more than capable of creating awesome software — why hinder them?
Yesterday, I had the pleasure of playing around with a piece of technology called the micro:bit. The micro:bit is a small hardware platform intended primarily for introducing young people to programming and tinkering. It’s a small device, not quite 2 inches square, but it is amazing. In fact, I’d say it’s probably one of the coolest pieces of technology I’ve played with in a while. What makes it so awesome? First, it runs Python. While I’m not primarily a python programmer, I do recognize that it has become one of the most widely used languages — not only for tinkerers, but also for professional development. This makes the micro:bit far more accessible to young people than C++ used by the Arduino controller (NOTE: I love Arduino, but the micro:bit is certainly more ‘kid-friendly’) The second thing I love about the micro:bit is that I had to install exactly nothing on my computer to get it working — no IDE, no flashing utility, nothing at all. The IDE is online, so you can type in your favorite browser and download the .hex file when you’re done. Flashing the device could not possibly be easier. When you plug the device in via a standard USB phone cable, it’s recognized as a USB thumb drive. Simply copy the .hex file to this virtual drive and within moments your device is flashed and you can see the results of your work. If the above weren’t already enough to give the micro:bit 5 stars, there’s more. The micro:bit includes an impressive hardware selection and associated API. There are 2 buttons, a 5×5 LED grid, accelerometer, magnetometer, and bluetooth. The form factor includes pads big enough to use alligator clips for interfacing with external hardware too — so you don’t even have to solder anything. While I’ve only tinkered with this device for a short time, it is definitely one of the more impressive hackable hardware pieces I’ve seen in quite some time. This needs to be in the hands of every elementary and middle school student interested in programming or hardware. The micro:bit is, in my opinion, a real game-changer.
Over the course of my career, I have seen all kinds of advancements in programming — some of them good, others bad. Today, there seems to be a trend to use all kinds of frameworks, design patterns, and technologies in an effort to save time. Unfortunately, what seems to save time in the short term often causes trouble long term. I must start out by saying that I’m not suggesting that all frameworks and technologies are a bad thing. For example, using an MVC approach for developing web applications is an excellent idea as responsibilities are cleanly separated between the HTML, the business logic, and the data access code. This works very well and improves maintainability of code. However, other frameworks are less valuable to me. For example, the popular lombok package allows Java developers to create data classes without manually creating the getters and setters for fields. This sounds like a great time saver as you can avoid writing code! But here’s the problem — it’s often useful to be able to find where variables are set, and you simply can’t do that if the setter doesn’t exist until compile time. Furthermore, this package saves little time since Eclipse has the option to generate (real) getters and setters already. Why is this package needed? I don’t believe it brings any value — just another technology for the sake of technology. In Android code, I see all kinds of frameworks being used. Unfortunately, most of them only obfuscate the code. While there is value in the MVP model, many Android activities are too small to really gain much from this model and the excessive number of interfaces begins to be a drag on development. Speaking of interfaces, they are probably the most overused design pattern. Again, I have to start out by saying that I absolutely love interfaces. Properly used they are one of the most valuable features of Java. Unfortunately, when everything becomes an interface and you need dependency injection to create the objects things start to complicated — often without any real benefit. Interfaces allow us to plan for the future — to admit up front that other implementations may be needed later. But in many cases this is simply never going to happen. Database code should certainly be written using interfaces wherever possible because it is not only reasonable but indeed likely that the project will — at some point during its lifetime — use a different database. Other things may make sense for interfaces too such as code for credit card processing, sending messages, etc. Ask yourself — is there a reasonable expectation that we will have multiple ways to do this? If the answer is no, why are you using an interface? Again, I have no problem with these technologies. But for me, my first choice will always be to use the simplest stock Java code I can and only move on to more complex frameworks when necessary. My code footprint is smaller, code is easier to maintain, and new developers can more easily move into developing or supporting frameworks with fewer complex patterns and technologies.