Programming, and all that goes with it

By now if you’ve read a few of my posts you know I tend to rant about things I need to learn to get over myself, things I feel are directly interfering with my ability to progress at the pace I feel I should be progressing both as a developer and as a person.

Tonight is sadly no different, though I promise I’m finally getting around to working on a legitimate tutorial again.

Tonight though, I’m going to harness the power of thirty-six straight hours awake to talk about something that has been holding me back, and a lot of fantastically talented people, and that is our ability to make excuses for why we aren’t writing the next <insert popular site here>. Read more

I’ve covered the idea of being programming language agnostic before, but looking back on it I’m not sure I was clear just how much I hate this trend of being a <x> language guy.

Let me start by being very clear. There is no right language, there is a right tool for the job.

Rather than rant and ramble, which I’m more than prone to, I’m going to do my best to give some examples of the right tool for the job.

Example 1: The wonderful places you’ll go (with Java) Read more

Business analyst, product manager, product developer, whatever you call them, they are often the first people to peer into the murk surface of an idea and try to discern shapes that mean something. A business analyst is essentially the first line of defense, and the most important, against all the forms of vaporware that plague organizations. They define the needs of an idea, help the idea-man/end user refine their thoughts into actionable items, and generally help fine-tune everything that happens before we write the first line of code.

A good business analyst is an amazing thing, they provide clarity and expertise that a developer working on a project may never gain into what something actually means. In medical software you might get a requirement that says “divide b-cell count by luminosity”, or some other obscure requirement concerning calculations. You write the code and have no idea why you’re doing it. What’s the impact? Why are we automating the division? Where do those original numbers come from? These are questions that a good business analyst will either know how to answer, or know who to ask. These are the things that can literally make the difference between designing a system to an end users specifications, and designing a system that actually works. Read more

And by “your” I mean “my”. I can’t deny, I’m pretty damned guilty of over-architecting. I’m one of those people who will see that I’m doing some fancy string manipulation in a custom helper method and I’ll think “Oh, I should gem that up, I might need that some day,” or worse yet, I’ll immediately ask myself if I need to put a service layer behind my app before I’ve even gotten down into the guts of what my app needs to do.

It’s a weakness, I like to geek out on the stack. Will I use ruby or jruby? Will I want a service layer, message buses, do I need to choose a heavier protocol or will stomp work, is http okay, what would I gain by going over SPDY (yes, even that far down the stack), this stuff is cool and what’s better than that?

Read more

I’ll probably never be accused of having an eye for design. I can only sit and marvel at the little touches great designers give to their products to make them a joy to see, to use and to experience.

The fact is, I’m not Steve Jobs. When it comes to designing my code, and the systems I build with it, I tend to focus on the practical. The “how do I make this work.” and, to the slightly more esoteric side, “how do I make this understandable.”

Now to be sure, making it work includes making it testable, reusable, all those things we think about as developers, but I never think “how do I make this beautiful.”

Why does that matter? Well, generally it doesn’t Usually when I’m working on something beauty has nothing to do with it, or if it does, it’s beauty in design not at the code level. That changes when I start working toward APIs and I’m forced to think “What would make this a pleasure to use.” Read more

“I don’t know, that’s just how we do it here.”

Never have more counter productive words been spoken.

There are literally millions upon millions of software developers in the world today, working in languages as varied as COBOL and ruby,  and in environments ranging from old IBM mainframes to modern-day supercomputers. With millions of brilliant mins constantly innovating you’d expect to see a lot of change, and for the most part, you do.

Github is a beautiful example. In July of 2010 Github hit its 1 millionth hosted project. Many of those projects are open source tools created by developers, for developers, and are the result of brilliant minds trying to find new ways to accomplish old, and sometimes new, things. Read more

One of the biggest questions when bringing agile into the enterprise is “How do we document requirements”. There are stories and acceptance criteria, human-readable code and TDD test results, all of these things provide a hodge podge of documents that can be pulled together to represent a deep understanding of system behavior, and may be understood by a fairly intelligent, tech-savvy user. These solutions do not provide what we need.

Agile developers have come up with a lot of different solutions as a result. Sometimes it’s trying to find a prettier way to format or name tests, other times it means handing the project off to a technical writer once everything is said and done. Amongst the solutions I’ve seen are video tutorials, UML charts and extended Q&A sessions with stakeholders and potential users.

UML, videos, Q&A and sprawling explanations written by technical writers all suffer the same fundamental flaw. In any project that is under continuous development, meaning regular version updates coming with potentially major, or even work-flow altering, changes, the cost of maintaining documentation grows exponentially. What’s more, those documents, which the development team has committed to maintaining for the remainder of the product life cycle, have no intrinsic value outside of being documentation.

There is, I believe, a solution. This solution requires a complete retooling of the development process from the very beginning all the way through final UAT.

Read more

The litany of the waterfall master or mistress is familiar to everyone in the agile community, many of the questions stemming from fear-based ignorance and an unwillingness to let go of the reins.

In recent years, as the agile movement has caught on, moving away from the fast-paced startup and embedding itself in the traditional enterprise environment the standard-bearers of Waterfall have taken a conciliatory approach, offering something I’ve heard referred to as watered-down waterfall.

Many of the tools in the hands of the watered-down waterfall evangelist are familiar to anyone who has so much as read about traditional waterfall methodologies. Everything from promising to use UML in an agile fashion, to adopting their own form of user stories that can make old-school waterfall documentation look brief.

By now, everyone in the agile community should be used to seeing these tricks and disregarding them, or else sticking them in a corner where they stay out of the way of clean agile processes. As the arguments have waned, an old but stubborn tact remains, the dreaded “Agile works great for other places, but…”. You can rest assured every time you hear these words that the person speaking them doesn’t believe agile works well in any form, but is simply trying to prevent getting your hackles up while they disregard any methodologies that don’t reflect the things they were taught in business school.

Read more

Every developer, over the course of years, builds up a toolbox. That toolbox may contain anything from the tools they use to format xml, to the image editing plugins they’ve had luck with.

Toolboxes are a great thing, they allow developers to cut down on the R&D time normally associated with green pasture work. A toolbox lets you go back and say “Oh, I’ve done this before, let me grab that code.”

But it can get better.

Read more

As a developer I constantly struggle to keep my ego in check, and I think many of us do. Ego can prevent us from forming good working relationships, can keep us from accepting good ideas and stop us from moving forward.

Learning to suppress your ego can be a difficult thing, and the more skilled a developer gets as they grow, the worse it gets. Some developers have developed a different problem however.

Recently when talking with a small group of developers about the merits of BDD I stopped to ask the most junior developer present what his thoughts were. When debating an issue that can get a little heated I like to take the freshest set of eyes available and get their input. This developer, we’ll call him Tom, responded that we were more experienced developers than he was, treating that as answer enough. Read more