As presented at Open West 2015
As presented at Open West 2015
As organizations build out complex systems in the cloud, writing reliable software gets exponentially more difficult. With each new piece of architecture, complexity rises, and software engineers lose visibility into how their code is executed. Less visibility means more bugs making it further into the software development life cycle. More last minute fixes. More late nights. It doesn’t have to be that way.
By making use of automated tooling, configurable convention, and lots of targeted communication, we can help to give the software engineers back their visibility. More visibility means fewer bugs, less frustration, higher morale, and that the overall quality of the codebase will improve! However, building tooling that developers will love takes proper planning and care. As far as end users go, these will be some of the most fickle customers you will ever build for. It is worth the time and effort though: Happy developers write happy code. Come learn how to delight your coworkers and build tools that will take your organization to the next level.
In this talk we will look at real tools built in the process of supporting developers building code for the cloud. Covering usability and utility, from local development environments to accessing cloud instances in an easy way, you will learn what developers want and need out of their toolchain, and how to give it to them.
Tools looked at:
Ruby (specifically Thor, and OptionParser)
Native desktop applications (for example, built in XCode for OSX)
As presented at Open West 2015
So often, we have to make decisions in the thick of things that we are unhappy with. Either it’s because we have other dependencies we are waiting on to finish, or because we have ran out of time, sometimes you just have to implement something crappy to get the job done.
The problem comes when we go back to excise those pieces out, often, if we leave ourselves any clues at all, it will be something like this:
And that’s it! That’s our grand plan. I’m sure whoever left that message meant well, and if they read it, they may even know what it means… if they still work at your company.
Now, my proposal isn’t actually that different. There’s just a step or two more you need to add.
First, your gating item needs a ticket. If you are waiting on the memcache server to be brought up, there had better be a ticket for the task of bringing that memcache server online. We will call this ticket OPS-1234. Next, create a technical debt ticket which DEPENDS on OPS-1234. We will call this new ticket TDBANK-4321. Side note: I like the tech debt ticket ‘stub name’ to be TDBANK because it reminds you that you are in fact taking out a loan against your long-term sanity, and encourages you to … repay it … as quickly as possible.
Now that we have our two tickets, it’s time to make our comment:
Not only do you see WHAT you are waiting on, but WHY, and every dependency of the gating issue is tied back to TDBANK-4321, which means you ONLY have to look at TDBANK-4321 to see if you can complete the instrumentation, and uncomment the pending code changes.
I have been encouraging this technique for the last year, and it has been shown to be beneficial on multiple occasions. Sure, it does “clutter up your code base” with todos and ticket numbers, but informed developers make better decisions, and tracking intentional tech debt becomes MUCH simpler if you decide to explicitly document when and why you make those decisions.
I see technical debt in the same light that I see version control and server configuration management: you are going to do it whether you want to or not. So choose to do it explicitly and take control of your process, before your tech debt takes control of you.
I once watched a TED talk where the speaker was discussing the fact that generally, we approach things the wrong way when we communicate. We will tell others about what we are doing. We will tell them about how we are doing it. The thing which we do not do enough, though, is talk about why we are doing those things. I thought it might help everyone to understand me, and where I come from, a little better if I told you about my whys.
Why do I work on the web?
The Internet connects us in a truly unique way. It’s like a technological worm hole. Suddenly, because of the Internet, the distance between any two points becomes almost negligible. In a world where we measure commutes in minutes, hours, or sometimes days and weeks, the subtle difference between 50ms to a local point and 200ms to Bangladesh seems quite trivial. It connects us, across the globe. The web, then, takes our new connected society and gives it a (mostly) unified way to read, create, and share. And boy do we love to share. We love to share videos. We love to share music. We love to share cats, and babies. We especially love to share cats and babies with little witty sayings stamped out on top of them. The thing we love to share the most, though, is ideas. Sometimes those ideas are bad, sometimes they’re hateful, sometimes they’re beautiful, sometimes they’re funny, and sometimes, every once in a while, they’re magic.
Why do I care about building software?
Software has the unique power to change how we, as humans, interact with the world. Software, of course combined with the hardware it enables, allows us, as a people, to affect the world in amazing new ways. Whether you are writing code for a bank that helps ensure money transfers work efficiently, writing for a startup who has found a new way to deliver cheese, or writing software that enables better communication in third world countries: you are changing the world.
When you learn to program computers, you are teaching yourself that nothing is as it appears. Everything is moldable, variable, able to be adapted and adjusted. Fluid. You stop seeing the world as a finite set of things, and start to see it as a current, but changeable state. The world is a set of problems that has yet to be solved, and I want to help solve them. However, I can’t do it alone, there’s just far too much work. I need help. I cannot do it alone.
Why do I place so much value on community?
I see community as the heart of software, really. Everything we do is iterative. Everything we do today is built on the shoulders of giants which came before us. Everything the next generation of software workers will do will be built upon our giants’ shoulders. However, most often, giants do not grow in isolation. The giants I speak of, to be clear, are ideas, not people. Mostly small, many trivial, but ideas none the less. Inside each one of us is a giant, waiting to come into being. It just takes the right set of circumstances, the right set of knowledge, the right environment, to bring them to life.
I see community as a way to feed those budding giants. I see community as way to take a junior developer, show them the ropes, show them how … squishy … the world actually is, and seed them with passion. I see community as a way to take mid-level developers and fuel their passion with ideas. Finally, I see community as a way to take senior developers and give them an outlet where they can refine their ideas, vet them with peers, and share them back to the community, fostering growth and innovation, spurring more passion and ideas.
I love PHP for so many reasons, but the reason I love it most in this context is because I consider PHP the “starter drug” of web development. Open almost any basic shared hosting account, upload an index.php file, and you’ve just taken your first step towards changing the world. Within the PHP community, we have the unique opportunity to catch these new developers just as they’re dipping their toes in the lake. It is incumbent upon us to welcome them, teach them how to swim, and more importantly, show them how to teach themselves to swim better. Faster. Farther. Even more, we can show them passion. Passion isn’t unique to PHP, but our proximity to those who don’t yet know that it exists is.
Why any of this is relevant?
I have an overwhelming desire to do. To create. To build. To teach. To do. But I want to do so many things, I’ll never get any meaningful amount of them done. The only way I am ever going to make any dent in my to-do list is to get some help. I’ll need more than some help, though. I’ll need an army. An army of ruthlessly competent individuals who believe they can change the world. An army who believes they will change the world. An army equipped with budding giants, prepared to tackle anything. Software is the great equalizer. Anything is possible. The solution may not be cheap, or the solution may not be practical, but there is always a solution.
Stay tuned for more! In the next installment of “The why of the thing” I will detail my ideas on how to build this army of ruthlessly competent individuals, and how that differs from the way we teach people how to program today.