September 2017 - Talixa Tech Blog

September 17, 2017November 3, 2019

What Language to Learn?

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.

September 15, 2017November 17, 2017

Developer Maturity

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.

September 12, 2017November 17, 2017

(Fr)agile Development

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?

September 1, 2017March 1, 2020

The micro:bit

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.