Managing technical debt extraction within a large code base

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.

The why of the thing

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.

Why PHP?

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.

What to learn to be a better developer

Back in 2013, I gave a brief talk at php[tek] which was about all of the things you need to learn along the way to be a developer. I promised I would put up the list from my notes — and as you can see from the date, I pretty much failed on that promise. However! I found the notes! So without further adu…

PHP Coder

  • Broaden your general PHP knowledge
    • PDO
    • Namespaces
    • OOP
    • PSR-0 (and other PHP-FIG initiatives)
  • Code versioning (Git, SVN, anything…)
  • Dependency Managers (Composer!)

PHP Developer

  • Design Patterns
  • SPL
  • Unit testing
  • Basics of encryption
    • Public and private key encryption specifically
  • Code smells

Web Developer

  • Javascript
  • HTML & CSS
  • UI integration tests
  • Protocols
    • HTTP
    • HTTPS
    • SMTP
    • TCP
    • UDP
  • Learn about build automation tools (phing, make, ant, jenkins, travis)
  • Learn about deployment automation (capistrano, dploy.io, etc…)
  • Pick up some solid Linux administration skills
  • Code smells (MOAR!)

Software Developer

  • Pick up more languages
  • More design patterns
  • More code smells
  • Better your testing approach
  • Programming styles
    • Procedural
    • Imperative
    • Functional
    • Object Oriented
    • Event Driven
  • Build on a new type of platform (notice the “web” in “Web Developer” went away up there?)
    • Build a desktop, or mobile app.
    • Build a server daemon.
    • Build command line tools.
  • Learn to do Security Model assessment

Software Evangelist

  1. Pick a new thing to learn, and learn it!
  2. Teach others what you just learned
  3. GOTO 1

A website for San Francisco PHP

So it’s time we made a real push to connecting more with the members of the San Francisco PHP User Group. To that end, step one for any web-savvy group is always a website!

Why?

I want to get a website built for SF PHP to allow us to better support and engage the PHP community: both the developers and engineers (however you wish to label yourselves) working in it, and the companies relying on it. I want to connect those two groups in meaningful ways to help promote the adoption, growth, and sustainability of PHP in the Bay Area, and beyond.

The purpose of the project I am looking at, at the moment, is to get the ground work in place. We need a basic site with a simple CMS system at first, but I want to add a lot of functionality to it eventually — incorporating logging in via the Meetup.com API, talk archive, videos on the site, articles by local developers, technology articles by local php companies, eventually hooking into a custom sf php mobile app for the meetups themselves – so I think starting from a custom stack is the way to go.

Secondarily, I would like the core group that builds the initial prototype do a dual-purpose meetup (perhaps in series, however it works out) which will both cover “introduction to Zend Framework 2″ and “Here’s how you hack on our site to add new features.” There’s a bit more I’m trying to work out with this, but I don’t want to say anything publicly until I know for sure.

The Mockup

mockup

 
I’m not super married to anything design wise, just trying to get some of the structure in place.

That center bit will either show:
– Next meetup
– Live meetup stream if a meetup is currently happening and has a live stream available
– The last meetup’s video
– Recent articles if there’s a given amount of time between the last meetup and the next one. Perhaps at that point we would put the last meetup’s video where the speaker bio is and have the recent articles in the zone on the left.

Basing it off of bootstrap or foundation would let us iterate faster in the group, I suspect, but I don’t necessarily have a preference.

Introduction to building a programming language

I gave a talk at San Francisco PHP last week all about what it takes to start building a programming language. For the example, I have built out a small implementation of PHP in JavaScript I called PHP.js. We talked about the process of what it takes to build a programming language, as well as why programming languages are made, and some of the decisions that get baked into them while doing so. It was a fantastic group of people and I had a lot of fun giving the talk.

Additional resources:

twitter