I love the movie, “Hidden Figures”. Starting with a heroine who is herself a “computer” to the historical education on gender and race discrimination right here in Virginia early in our space program; the hidden computer science history in a local context is as dear to my heart as the characters’ stories. This was a movie I thoroughly enjoyed and appreciated along with the entire family. I highly suggest watching this movie with your family, friends and colleagues and expose more people to critical technology evolution history that has been overlooked.

One of the things we teach in our Computer Science curriculum at Tech Em is how the term computer was used for human calculators. So, to see this played out on the large screen while also clearly showing one of the first instances of job deprication due to advancing technology is exciting. And, it is not just entertaining historically based storytelling, but a wake-up call to all — to excel in technology is not always about traditional background and education, but more about openness, acceptance, and the passion to keep learning and applying knowledge using the emerging tools.

A measure of these women’s brilliance is that they accepted where technology was going and took action, immediately arming themselves with knowledge about the new systems and how to program them. Okay, my kids didn’t really get why my wife and I were laughing when Dorothy gets a FORTRAN programming book from the library:

FORTRAN, Language of the Future

Dorothy Vaughan went on to become one of the leading FORTRAN programmers in the world.

Many of us in the IT field know — that along with the advancement of hardware/network capabilities, we see cycles of the similar patterns applied within the context of the new capabilities to take advantage of the improved hardware/network performance. These cyclical patterns take the form of newer languages, frameworks, programming paradigms, and more recently black boxing of large-scale services (IaaS and PaaS) on which to run systems. However, are we thinking about today’s analogy for the IBM 7090 that was featured in the film? It is clearly cloud computing. And while cloud is definitely the opposite of huge pieces of machinery (that won’t even fit through the door), the potential impact is much farther along the exponential curve of computing advancement. The current major advancement, cloud computing, is closer than your place of employment in a room that requires approved physical access; it is right here on your web browser in the form of AWS, MS Azure, and Google Cloud Platform consoles! Take a cue from history and learn how to leverage and evangelize the cloud just as Dorothy Vaughan taught herself FORTRAN and shared that knowledge with her colleagues.

I have certainly become a cloud advocate and highly encourage everyone to explore the capabilities — especially around serverless. Seek out cloud training and certifications to ensure you are armed for the future just as these women did. What’s more compelling is that you don’t need to be a part of a large organization to implement an application or service that is immediately available and scalable to all. I truly look forward to hearing about the “hidden figures” of this cloud generation — in fact, they may not be hidden at all, but immediately visible to all through their novel application of these services that enable immediate scale.

One can imagine that in 50 or 60 years, using the term computer to refer to some physical machine will seem as silly as the term computer referring to a human. We are already thinking more of the computing act as a service and not a thing — as in cloud computing. Programmers will likely become AI agents in the cloud that will perfect your overall solution with self-verifying software. So, take a cue from the movie and take the first step: teach yourself cloud computing [infrastructure as code]: Language of the future.

Hidden Cloud Advice in “Hidden Figures” was originally published in The Art of Tech Training on Medium, where people are continuing the conversation by highlighting and responding to this story.

Technical Debt is one of those buzzwords that is being overused and misused to refer to any coding or platform research activity that is not directly part of a shippable product. Abusers of the term are requiring developers to justify the very tasks that nurture creative and well-Engineered solutions.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. [Techopedia.com]

Ok, got it, and we’ve all been there: adding ‘XX’ or ‘temp fix’ or ‘kluge’ in the comments for a method that we should revisit before it is too late. Thus, while better programmers are lazy programmers, the best programmers consider not just their current level of effort, but also their future level of effort and all future developers’ time and effort to maintain or enhance a software system — intuitively understanding through training and experience to avoid so-called Technical Debt. So, I appreciate highlighting the risks associated with prioritizing time to market over future costs. However, I don’t appreciate the generalization of the term to cover any tangential research/coding exercise, often wielded by those who are not plugged into the stream of commit messages that provide the actual details of what is going into the product.

Having worked in IT for over 20 years — I’ve been on many projects that include inheriting pieces of failing software systems; I truly appreciate and understand the costs (compounded over time) associated with Technical Debt. Technical Debt will snowball and transform a software system into a growing ball of duct-taped spaghetti that becomes intractable. However, we used to more accurately refer to processes and systems not built with maintenance (and all the other ilities) in mind as not well-Engineered. Furthermore, the root cause was likely inadequate understanding of non-functional requirements, design without traceability, bad planning or even the classic POC goes into prod as a POS; most developers understand long term costs of software ownership and, if anything, may over-engineer a solution to be future flexible so I’m not sure I even agree with the Techopedia definition — personally, I have many times added development effort for future flexibility. Pattern overuse and anti-patterns probably contribute more to technical debt than simply code that is easy to implement in the short run.

Obviously, this metaphor is best explored from an Economics and Engineering view. Ultimately, you are trying to build something that optimizes efficiency. In monetary terms, therefore, you want to build software systems (and related processes) such that their total cost of ownership is well below the value they create. And Software Engineers know that mainentance is the longest phase of the software lifecycle so, along with solid verification and validation processes and tests in code to seed lifetime regression, they attempt to reduce the cost of enhancements during products’ maturation by making sound Software design decisions that support component modularity (balancing coupling and cohesion) along an ideal line of Abstractness and Instability.

Consequently, taking this Software Systems Engineering view allows one to realize that any Engineering system will include some intrinsic form of debt — mostly in terms of future cost of maintenance, but also in terms of probabilistic risk (i.e. failures). We strive to design and build systems to minimize both (the so-called technical debt). So, yeah, what exactly do we mean when we freely throw around the term Technical Debt? And why is it bringing new critical focus on some of the most rewarding aspects of being a relevant software developer — researching and building things with emerging frameworks and technologies?

Yes, I get the context of the term to raise awareness that some code just smells and that not all code is equal, especially code produced in haste to meet a deadline. Some code should be, from the beginning, throw-away and we should understand that and not attempt to prolong the use of sub-par code in an effort to meet “Agile” demos that prioritize time to market over long-term resilience. But, is this not avoiding negative NPV? Please don’t tell me to stop all my side fun projects exploring potential solutions because it is Technical Debt; put my accounting hat on and I would classify most fun tech research as technical invesment. One can relate to personal experiences— my one weekend installing slakware in college yielded a far higher return than many semester long college courses.

Living on a small farm complete with dogs, cats, chickens and horses, my family knows the value of waste. In fact, most waste, is in fact, not waste, but valuable resources for future growth (i.e compost).

And now, in an apparent effort to stifle research, exploration, utility, and basic farming methodologies, anything not part of the final production process is deemed Technical Debt? Any code producing endeavor as a potential creation of technical debt is questioned. And this simply highlights the misunderstanding of the mad scientist side of Computer Science and programming — the creative and artistic act of building things applying the latest tools and techniques.

On a recent project, our scrum master actually recognized this aspect of development and felt these exploratory efforts would be better captured as Technical Waste as opposed to Technical Debt (we all acknowleged this code would not be in the final product and was pure R&D). However, I would like to take it one step further and call it Technical Compost. You see, the best software has come from the decomposition of previous projects and code playgrounds, just as our best vegetables grow out of our food/farming waste. As Engineers, we are taught to “throw away” our first solution. In fact, according to Brooks, we should actually avoid the The second-system effect and thus pile several trials onto our compost to enhance the future results. As a farmer, I know the best crops do not come in the first (or even second) season. And as Artists, we learn to evolve, paint over and refactor our doodles into elegant works of art.

So, think carefully before you strive to meet Management’s desire to avoid technical debt and help everyone understand that we are often amassing matter to grow better software in the future. In fact, most developers are like me in that we actually save much of this compost (as non-proprietary doodles) in our repos and gists to jumpstart future products while refactoring using the latest technologies and platforms. Consequently, code compost is actually better than the organic kind because its nutrients don’t degrade as quickly over time!

Happy Software Growing!

Stop Calling My Fun Technical Debt was originally published in The Art of Tech Training on Medium, where people are continuing the conversation by highlighting and responding to this story.

So, first off, how cool is it that we can relive our childhood passions as adults with our own kids?! And what raises the coolness factor even more is that this particular endeavor combines fun with the kids, my own passions and a unique opportunity for learning and using skills relevant to most IT professionals. Yes, you get the exhileration of a rocket launch powered by all the fly technologies: Alexa Skills Kit, AWS Lambdas, Slack integrations, and Python Raspberry Pi Slackbots using GPIO libraries.

At Tech Em we are constantly trying out new ways of teaching technology to kids — often times the ideas that garner the best results are the ones that harken back to what learning technology was like for me during the 80’s. In fact, getting Computer Science students back in touch with the bare hardware is part of the inspiration behind the Raspberry Pi, which is certainly why we love them. I learned a lot about aeronautics, circuits and making (before that was a thing) from model rocketry as a kid and that holds true today.

Rather than pushing children to think like adults, we might do better to remember that they are great learners and to try harder to be more like them. — Seymour Papert

Something Tech Em doesn’t do is shy away from utilizing the same tools that real Software Engineers use, cause I certainly wish I had Emacs on the TRS-80! Seriously, part of learning the art of programming is learning source code control, testing, continuous integration, cloud computing, design thinking, and how to coordinate with a team both virtually and in person. Not teaching the proper tools and techniques is like trying to teach a carpenter apprentice how to nail down the subfloor (and extract nails) with a plastic hammer.

Consequently, the evolution of the “Alexa, launch my rocket” project first started with an idea to build upon the Python coding projects we do on the Raspberry Pi and mix them into a Slackbot, giving the kids a user interface they understand, instant messaging. We had already setup our students on slack to correspond about classes, assignments, and allow them exposure to business text messaging. Furthermore, we had already introduced our coding classes to GitHub with at least one repo for each class and the GitHub-Slack integration so they could all watch and learn about source code control and working on development teams. The slackbot project is a great mix of 80’s style non-GUI coding using today’s technology and professional tooling.

Essentially, our slackbots run as a Python app on the Raspberry Pi. The slackbot watches for specific commands to execute custom functions. Because, we are running Python on the Pi, we can use GPIO libraries to interact with the physical world. For our student projects, the interactions are typically things like turning on/off LEDs and reading sensors/pins. The Mission Control launch sequencer actually cranks this up a notch because we are dealing with higher voltages and ultimately rocket engine igniters. We need to ensure a safe and proper sequence (state transitions) and ultimately minimize the delay for the final step in the sequence just in case the wind kicks up or a dog wanders over to the rocket. We use some on board LEDs not only to indicate state to the ground crew, but also for checking status using the GPIO libraries by the Mission Control software. Did I mention this is an awesome teaching project?

For the slackbot development, we have each class work on a repo together; using Python packages, each developer has her own custom command/function file that is combined with all the others during the automated build. For every student git push to master, we actually use Travis-CI to build the classes’ code, run our tests, and deploy the slackbot app as a library to PyPi. The class Raspberry Pi (or Pis in our studio or at my home) use cron to regularly check for updates to the slackbot (via pip install) and restart. Yes, the slackbot uses the Slack Real Time Messaging API connected to the team Slack channel firehose of messaging and runs just fine on a Pi.

These projects have been extremely fun and rewarding and, most importantly, they are the epitome of modern applied computer science. The students are contributing to a common open repo using Git, having a cloud (container-based) CI/CD build and test their changes (with each step logged in slack) and then deploy/upload to a standard python library repository. Anyone can pip install the project on his machine to run the unit tests or simply wait a few minutes and execute the code on a Pi. And they can do this directly in the GitHub editor at home — to affect the Pi in their classroom miles away! And slack is the user interface to control their custom IoT device.

Enter Alexa. I reused the Slackbot project to quickly build a proof of concept for a client that went a bit further. The slackbot for that client demo took commands to get and set data into a cloud database (AWS RDS) of topics and then monitored slack conversations to track activity on those topics. And to fully build out a compelling demo, I added an Alexa skill that read data from the same database. An exciting portion of the demo was simulating conversations in channels that mentioned topics and then asking Alexa about the trending topics. Yes, back to basics of CRUD, but within the world of instant messaging, serverless, cloud compute and store, capable IoT devices and a voice interface.

While preparing the demo I sort of created a bug. One of the things I do with lambda services is drop progress messages in a slack channel. I have slack up all the time, so may as well use it as a debugging tool, right? Anyway, this logging was also being picked up by the slackbot! Ultimately, I restricted the channels that the slackbot monitored, but I knew what this meant — I can send commands to the RPi slackbot via a simple Incoming WebHook to slack from the Alexa lambda service.

Enter Estes. I have been launching rockets with the kids for a few years cause, well, I have always loved model rockets (and really anything Aerospace Engineering related). I also had on my personal backlog to launch rockets using a RPi. However, I had always thought about having the Pi supplement a fancy led launch timer/sequencer with perhaps some other telemetry recording capabilities. I don’t remember the actual moment now, cause early this year, my kids and I simply understood — we should ask Alexa to launch our rockets. Not only would it be really cool and fun to build the rockets, the code and the wiring/circuit (transistors are a big part of Tech Em’s curriculum and this project requires a bigger TIP120 power transistor), but also it would provide additional safety since we could stand farther away, wirelessly!

The Mission Control commands that ultimately fire the rocket present a nice problem for new Python developers to solve — don’t allow just one command to launch the rocket, there must be a specific series of commands issued before the launch pin is energized. The requirements go like this: 1) the Pi must first be armed, which shall light both the red and green LEDs on the case; 2) the launch can then be commenced (iff both LEDs are on), which shall then blink and turn off the red light and leave the green LED on; 3) finally the launch command can be processed, which shall start the green LED to blink quickly and turn on the launch pin within 3 seconds; 4) the launch pin is turned on for at least 1.5 seconds to energize the transistor to allow the 6V circuit to close such that at least 600mV goes through the rocket igniter long enough to generate the spark. The recommended solution is to actually use the LEDs to manage the state, reinforcing how to turn on and off pins as well as check their status.

Likewise, the Alexa skill and lambda service is relatively straightforward, but we enforce similar safeguards. The requirement for the skill go like this: 1) A user must first request arming; 2) followed by a request within the same session to initiate the launch sequence, which starts the countdown; 3) a final check must be made before the launch command is sent to ensure the field is clear, which finishes the countdown and announces the blast off. Thus, this requires dealing with session attributes, allowing an abort up until the final roger roger. If one tries to break the sequence, alexa will scrub the launch and send the disarm command. And because the skill logic is implemented in lambda, we can continue to leverage Python that happens to be running serverlessly in the cloud.

I’m making all the code available in GitHub with the commiserate warnings about model rocket safety and the recommended process to be safe while having fun. We, of course, have several improvements in the works and will ultimately focus on Alexa, the RPi and launching rockets, but from a teaching and tech education perspective, this initial project is terrific at tying together a bunch of buzzworthy technologies, applied computer science, and maker skills into an exciting, tangible, event for all ages.

My friend calls me the Cloud Maker. I think my kids and I are more Makers of things for the Clouds using the Cloud, but that doesn’t roll off the tongue.

Teaching Kids to Code with Alexa, Raspberry Pi and Rockets was originally published in The Art of Tech Training on Medium, where people are continuing the conversation by highlighting and responding to this story.

Python’s rise in popularity has been amazing to witness, especially for a 20+ year Python fan. Flying Python on AWS Lambda services in the cloud takes the language to new and exciting heights.

Python has been a go-to language for me since the mid 90’s. Currently, it is my preferred language for teaching kids (including my own) Computer Science and programming. Many of the students’ Python programs end up running directly in front of us on a RaspberryPi; very much on the ground and far from the clouds. We have dozens of lessons combining Python and the Pi and sensors and LEDs and even Minecraft — exposing kids (and adults) to coding and all the nuances of hardware, from wiring to Linux configuration. It was difficult to then cover elementary aspects of distributed and cloud computing without a lot of hand-waving and boiling down the hours of pre-work/configuration we had done to prepare their environments in the cloud. With CI/CD tools, we can make cloud deployment very easy for the kids, but it was unlike the Pi projects where they are actively involved in all the steps. Abstraction can be a good thing for a professional organization, but openness and clear-box hands-on experimentation is best for instruction. Unfortunately, our students’ learning about the cloud wasn’t much more than drawing a cloud on the whiteboard with a bunch of boxes floating around and leaving the details of how to run code in the cloud for more advanced classes.

Enter lambda. Now, we can take the same basic Python programs that kids have written to learn how to code and upload them to lambda services. This is an amazingly simple trick with incredible results. Imagine how fun this is to teach —“take this simple function and copy it in here and now it can be invoked anytime, from anywhere, any number of times”. It provides us the perfectly simple platform to compare/contrast running code locally with running code in the cloud. Oh, and take that crude text-based command-line interface and replace it with SSML and now elementary python code becomes the engine behind a skill invoked by your voice, anytime, anywhere, pretty much for no cost: “Alexa, thank you”.

Please, pause and contemplate where we are with this. Take your tested code, move it to the cloud and with no server config and very little network fanfare and it is runnable by the world. Period. So easy, an Elementary student can do it after only a few hours of Python introduction.

If this doesn’t make everyone want to learn Python (or even Node.js), I’m not sure what else will. AWS Lambda services, with the help of Python, is a critical turning point in the industry. Java entered the world with its vision of write once, run everywhere — leaving out the harsh details about distributing that code everywhere onto platforms that are not close to being uniform with variations that are impossible to test. Code bloat was immediate and containers implementing specifications to protect ourselves from ourselves continue to get in the way of standing up simple services that scale. Python on Lambda is write once, and call from anywhere and everywhere where all execution (and thus monitoring and logging) is centralized. The Lambda “container” is the epitome of simple, and the statelessness ensures a focus on API-oriented functions that can immediately scale; using methods that focus on code-first, configuration-never. Is this not the evolution of convention over configuration and opinionated frameworks?

The 1997 me would think that we have come full circle back to DCE and Encina and its stateless procedural services, and in some ways we have; except for the fact that we (well, AWS in this case) have mastered truly large scale distributed server(less). We now truly achieve the goal of writing code once and deploying it easily once to one virtual location that is executed when needed, not how configured (and no rpc_ss_allocate :) ). Oh, and to reinforce the simplicity; it is easy enough to explain, code, and deploy with a fifth grader — try that with DCE, CORBA, EJB, Rails, Django, Angular/Node.JS, JHipster, …

So please, if you haven’t done so already, please go fly some Python snakes on a Lambda plane and clear your mind for innovation and differentiation instead of configuration and scaling optimization. Then, share your learnings with kids and build an Alexa skill or two. And you needn’t worry if you are deploying a service for the masses (the killer app), for these snakes will scale!

Python in the Clouds was originally published in The Art of Tech Training on Medium, where people are continuing the conversation by highlighting and responding to this story.