Agile does not mean...

Rushing code to production

For some unfathomable reason, it seems like most people think Agile means getting new code out the door as quickly as humanly possible, if not faster.

A sprint is taken as "we can release new stuff every 1 or 2 weeks!" which leads to the sales drones thinking "the customers will love us!". Its all about fast turnaround to new features. The sprint is turned into the tech equivalent of an assembly line or sweat shop, churning out deliverables at a break neck speed.

The idea of an MVP is reduced to "Whats the minimum possible thing we can get away with doing just so it looks good on a feature checklist". Because of the sprints and supposed rapid development, it is thought that you can just flesh things out later.

This is bad both for the customers and for the developers.

For the customer it can mean features that don't really work, or work only within narrowly defined areas. But customers are notorious for exploring features and they will quickly realize the limitations if you don't properly design the feature. They will complain. They will get frustrated. Especially if the feature is what sold them on your product. You are better off having a few features that are well implemented than to have a ton of features that are for lack of a better term half-assed. Even worse is if you have bugs even with the part you have implemented because you didn't take the time to even test what you've created.

For the developers it can mean a complete breakdown in proper development processes. Because process goes out the window, except for the sprint. And even a proper sprint can be pared down to nothing more than "get x features done by this week". It means no real planning, no testing, no discussion between developers. It results in developers being told to implement features in isolation, churning things out without mind to the bigger picture. Or even going behind the backs of senior developers just to get things out quickly.

The short of it is this: You are going to piss off your customers. And you are going to piss off your developers, particularly your senior developers because they've seen this happen before.

What Agile is not...

Agile does not mean no planning.

Traditionally, agile is presented as the antithesis of waterfall style development. In waterfall, you do all your planning and research up front and create a definitive specification of the development plan, the features and functionality and even delivery dates etc, and you do not deviate from the plan.

In Agile, you do none of this. You essentially throw the baby out with the bath water. You don't plan, you change direction on a whim, throw in new things, etc.

At least that's what most people think. At least in my experience. But this is not what agile is. Agile does not mean you do no planning.

Agile means you do your planning in smaller chunks, filling in the details as you go. It means being able to make modifications to the plan on an iterative basis, after getting feedback.

Instead of exhaustively documenting every possible thing up front, you create an outline. And then pick one thing to work on, and plan that thing out for a short period of development (the so called Sprint). Once you've done your sprint, you circle back, review the plan, get feedback and maybe make modifications to the plan. And then repeat.

Without a plan, without reviewing the plan, without the feedback loop, agile is just barely controlled chaos.

Top ten reasons you left your job

I've had a few jobs. I've only quit a few jobs. Most of the time, it's not my choice to leave. Here are the top 10 reasons why I've lost a job:

1. Company decided to axe project you worked on for something new
2. Company couldn't afford you anymore
3. Same company as #1 hired you back to work on 'legacy' system, then decided to axe it again as well the new system that replaced it and just not do development at all.
4. Company didn't feel you were 'invested' in them. Because you didn't go out to lunch with the team everyday.
5. Company owner was running a development ponzi scheme that eventually collapsed.
6. Company bought an open source project then gradually killed it while promoting their non open product.
7. Company wanted to steal the software you developed in partnership with them, so they stole the source code off your laptop while you were in a meeting and then showed you the door. *1
8. You took a week off to deal with a death in the family and when you returned, they fired you. *3
9. You worked for a subprime mortgage company in 2008 *2
10. You worked for a dot com in 2000

* 1. Decided to rewrite software from scratch, greatly improving it.
* 2. Companies using your rewritten software all went belly up.
* 3. Subsequently sued for wrongful termination and won

Display Cup prototype

So I had this idea. What if you took one of those flexible e-ink displays and wrapped it around a coffee mug so you could have a programmable cup?

It's actually been harder to do that I thought. Mainly because I haven't found a decent cup to use. I attempted to fabricate one from acrylic sheet that I wrapped around a cylinder, at a size that would allow one of those "I am not a paper cup" coffee cups to be inserted within it. This didn't work out so well given that I didn't have the best tools on hand.

Then I remembered how my kids made custom mugs years ago, using these cups that have a clear outside with a cup insert. I had a hard time finding them though, but finally located one at Hobby Lobby. Unfortunately, they are really flimsy (but also really cheap.. less than a dollar). But it worked for a prototype.

The electronics are pretty simple. I used a Lolin ESP32 lite, because it has a built in battery charger, Bluetooth LE, and enough memory to store lots of images. It's probably overkill on the processing and memory needs, but it was convenient to use.

Attached to this is a Waveshare 2.13" flexible e-ink display with its driver "hat". I have not be able to find anybody selling any other size of flexible display. This one is easy to find on ebay and ali-express.

Finally, I got a little 150Mah Lipo battery with JST connector.

Luckily, the space at the bottom of the cup under the insert was just big enough to fit all this in there when arranged just right. I taped it all down to a thin round of cardboard.

 Once assembled and tested with real coffee I discovered that the display doesn't particularly like to be warmed to the temperature of coffee, and begins to fade! Also coffee doesn't stay warm long. So I improvised some insulation by taking a styrofoam cup and cutting off the bottom and then wrapping it around the cup insert. This helped a great deal.

Again the cup is really low quality and only barely usable as a novelty, but, it's pretty cool having a cup with a display that changes while you are using it! The battery lasts a few hours on a charge with the display changing every 30 seconds and putting the ESP32 into deep sleep.

I am working on a more practical version using a double wall insulated ceramic or metal cup, and going back to fabricating my own acrylic outside holder.

Development Process: weapon of choice.

I was asked the question "What is your process when developing an app". I was not exactly prepared for an answer, much less one I could deliver as a short 30 second pitch for my skills as a developer.

But it got me thinking. I do have a process, even if I've never codified it. Part of this process involves my secret weapon (though not really secret).

Maybe I am just old. But I still enjoy paper, and really anything paper related. Even as a child, I always had a pad of graph paper for recording my ideas. But that's not my secret weapon.

The venerable pencil is my weapon of choice. The pencil is to me what a wand is to the magician. Its a tool to focus my "magic" and channel it where I want it to go (usually onto graph paper, but a nice Moleskine notebook is also good, as well as the proverbial napkin).

For me, holding a pencil in my hand allows me to think in a serious manner.

That is where my process begins. By putting ideas onto paper. This, for me, makes things real. The flurry of thoughts in my head coalesce into words and sketches and are recorded more less permanently. A pencil, as opposed to a pen, allows revisions and updates where needed.

First, a simple list or even tree of idea points, features, and even references to other related things. After that, some visual sketches. This in particular is where graph paper comes in handy. With all the technology, the styluses, the touch screens, still nothing beats a pencil and paper.

But we are still talking about application development here (actually this is my process for everything, from how to restore my kit car to developing a recipe), so eventually I will transfer those ideas to a "mind map", my favorite tool for this being Mindmeister. I like the simple, purpose built tools.

Now, I like agile as much as the next guy, but you are kidding yourself if you think you can bring any reasonably complex project to fruition without some kind of plan. This is why I like to create a functional specification document. Yeah, I know, this starts to sound like big corporate speak and more like waterfall style development. But honestly, if you can't describe your project in a few pages (or even one page to get the gist of it) you probably have a problem.

Think of your functional specification as a sort of pitch for your idea. It's as much for other people as it is for you to help you stay on target. Keep it to the minimal requirements too. Just what is needed to make the thing viable. It's like writing a short story, you only throw in what is absolutely needed.

Getting down to actual development, I might use a tool like Ionic Creator to rapidly develop a prototype to show other people. At this point I've probably also got a kanban board (Trello is a good simple tool for this) as well as bug/task tracking (I'm often forced to use Jira but I prefer simpler tools like Fogbugz). I cannot remember what I need to do without tracking it, so these tools are invaluable. I shouldn't have to say it, but use version control (Git). Use branching and tagging to track versions and releases and lines of development.

The rest is a series of iterations over adding features, testing, refining, testing and more testing. I cannot stress testing enough. Think about every edge case. Every "user story" (you should have some of those in your functional specification). Keep your iterations short, that's really the meat of agile. And if something doesn't work out, don't be afraid to back up (you are using version control right?) and try it a different way.

Oh, and listen. Listen to your client. Listen to other developers. It's easy to develop an ego and start thinking you know what's best. Most times you may be right, if you've been doing it long enough. But sometimes you will be wrong. Listen to what others have to say and be willing to accept the good ideas. Unless you are just building this for yourself, you need to understand not everybody thinks the way you do. Sometimes, a compromise must be made to adapt to what people want.

Am I just old?

When I sit down to do some thinking about an idea, I don't do it at the computer. No, I still prefer my trusty pad of graph paper.  Or if that's handy, any piece of paper, napkin, or whatever planar surface I can use to physically make marks using a writing implement.

Am I just an old fart, stuck in my non electronic, obsolete ways?

Or is there still just something missing from our modern electronic devices? We have super advanced, powerful computers. We even have tablet devices meant for semi-physical human-computer interfacing. Some even have writing implements, in the form of inert "styluses" you can use to simulate writing and drawing.

Aside from the fact that these technologies are still lacking the satisfaction (to my old person sensibilities) of actually physically applying some mass to a textured surface in a more or less permanent fashion, and that these old methods are still generally far cheaper, flexible, more portable, more viewable and do not require power or any additional tools (the device itself, apart from the storage medium) to be consumed by anyone you share it with, why do I still not find myself using technology for my creative process?

Now don't get me wrong. I love technology. I'm a software developer for crying out loud! And I wouldn't dream of doing any kind of significant writing using pen and paper (unless it was stylized writing like calligraphy). I'm using a blog on a computer right now.

But when it comes to thinking things out, its back to paper and pencil. Or a whiteboard, if I'm trying to convey the ideas to other people or working with them. And while I'm doing it, I am thinking, its too bad I can't index these ideas for later searching. I know that it will be hard for me later to go back and find the things I've jotted down, modify them if needed, etc. So I think to myself, maybe I will scan the notes back into the computer for later use? Nah, too much trouble. And now I'm getting distracted from the idea I was trying to put down.

That's what is wrong with the technology. Its still too complicated. Yes I can bring up a note application. But it may be restricted to just to-do lists, or plain text. It forces me to give it a filename and save it. Maybe it doesn't even then offer the ability to index the data (because its trying to be simple), thus eliminating one the main reasons to do it on the computer in the first place.

Where is the app that is as simple to use as graph paper, yet as flexible as a pencil and paper, but still allows the technology to be applied later for the things it is useful for? I have not seen it. And this idea is not something I just thought of. I've been thinking about it for probably 20 years. Maybe I just haven't seen it yet.

Where is my electronic graph paper?

Rockstar Developer

Most days my wife asks me, "were you a rockstar at work today?".

Well lets see.  Did I perform an amazing set of music while intoxicated, only to follow that with more drinking and partying with groupies backstage?  Was I overbearing and egotistical because I really think I am "all that" and more?  Was I allowed to get away with being a general asshole because I'm just so damn good at what I do that people are willing to put up with me?

By that definition, which is what most people think of RockStars, no.

Is that what most Rock Stars are, though?  Yes, a lot are, but not the really truly good ones.  The ones who have staying power, the ones who really do justice to their art, are much more than this (though they often go through this as a phase).

I keep hearing about the Rock Star programmers, who are uber nerds lacking in social skills but so talented they are allowed to essentially be assholes, or at the least so socially dysfunctional they have to be kept separate from the "normal" folk in a company.

And I think to myself, am I good enough to be considered a Rock Star?  Am I a big enough jerk to be considered a Rock Star but talented enough to get away with it?  Do I want to be this kind of Rock Star anyway?

What about those who are not Rock Stars?  Does this mean you are just relegated to being a "Code Monkey", cranking out code like an assembly line robot, counting the hours until the day is over and being bored out of your mind?

Lets take this analogy all the way and actually look at what good Rock Stars do, and musicians more generally.  You have your band, consisting of the "Rock Star", usually the "Front Man/woman" who is generally the public face of the band, who probably writes a good amount of the music and lyrics and performs most prominently.  The other band members may also be Rock Stars too, in varying degrees.  Depends on the band, of course.

Almost every Rock Star or band of Rock Stars also makes use of what are called studio or session musicians.  These are people who are also very talented at what they do, but they don't generally get the public recognition that the rock stars get.  They do their work more behind the scenes but are also integral to the sound and production of polished music.  They may also perform with the band as backing musicians, and are often no less talented than anyone else, they just aren't "Rock Stars".

This applies also to programmers.  "Code Monkeys" are like session musicians and are just as important as the Rock Star.  However they get little respect.  A rock star programmer often has many other programmers contributing to the project, and wouldn't be able to be a rock star without their support.

So what makes the rock star programmer a rock star?  Its not just being excessively talented at that one thing, and its not about being a diva.  Being a rock star means being talented at a number of disciplines, and being disciplined in general.  A good rock star is actually appreciative of the support network that allows the rock star status.  It means being a professional about the work, and even loving what you do.  A rock star is more than just being technically proficient but also having creative insights into what you are working on.  Being an architect, and not just a construction worker.  A rock star should also raise everyone up with him, because he knows he used to not be the rock star.  A rock star knows when to be a leader and when to follow and does not let his ego get in the way of the right choice.

Every session musician or programmer has the ability to be a rock star some day, but loves what he does enough that it shouldn't matter, because he knows both roles are important.

So, some days, I am a rock star.  And some days I'm a session musician.

Imagine Dave Grohl vs Kanye West.  One of them is a consummate musician who loves what he does, shows appreciation to others, and is just a generally nice guy and very successful at what he does; and the other one is Kanye.  Just sayin.