Programming, and all that goes with it

Ah, and we’ve made it to another segment of this little series. Today we’ll focus on the architect, what he is, what he does and why he matters.

In some situations the architect may be replaced by a generic manager, but I will state straight out that if your manager is not/was not a developer in their career, you’re better off letting your developers fill the role ad-hoc. The architect has to be able to see all the angles, but without a strong technical background it is nearly impossible to understand the development position.

The architect ultimately makes decisions and argues the case of the development process to any interested business units. It is a particularly demanding job requiring a mix of political acumen and people skills. Read more

So far there’s a word I’ve used sparingly in this series, and have mostly avoided when I could. That word has been agile. Agile represents a huge range of skill sets, suggestions and best practices. It’s a phrase that has been bastardized by many to simply mean “We can wing it”. That isn’t what agile is about. I’ll state this very clearly, agile is about creating a workflow that can reasonably and quickly adapt to user and business needs by uncovering those needs as early as possible.

Agile does not mean “I know you just launched this yesterday, but I need you to add a few features by tomorrow”. We attempt to create a workflow, to get input and feedback in a constant loop from users, and to never need to push out features that are created under highly undesirable circumstances, such as all nighters ending in a early A.M. release.

Why? Because those circumstances suck for the code quality, the developer and ultimately for the business. Bugs are introduced, mistakes are made and sometimes tiny, hidden inconsistencies can create very serious results. The process is not there simply to make us happy, it is there to make what we produce better.

The reason for this rant is that I’ll be using the word agile a lot more in this and future posts in this series. I wanted to get that out of the way before I started.

On to the Business Analyst now. Read more

Every GUI project has a user of some sort. Whether enterprise or commercial there is always someone who, in the end, will interact with your system in a very real way. The user is the purpose of the software, and it is the user, or a user advocate, that usually gives final approve on whether or not the software does what it is meant to do.

Commercial software in particular makes use of user advocates like product specialists and business analysts. Their job is to behave for certain parts of the workflow in the exact manner that an enterprise user might behave when internal software is being built. Beyond this introduction I will refer simply to the user, which will refer to whichever is applicable to your situation.

The User Timeline:

The user is involved in nearly every aspect of the ideal software development lifecycle. By involving the user all the way through, with no long gaps in user interaction, a software team is able to take a more agile approach to development and changes.

Because of this, the user has the longest timeline of anyone, they see the start and finish of the software development lifecycle, and continue to partake in it even after most of the software team has moved on, providing information for improvements, bug reports and the like.

Read more

Okay, yeah, the title is a little bit of link bait, I admit it. Deal with it.

Internet Explorer has started to gain a small following in what I can only guess is some sort of developer-hipster hybrid community, and I’ve got a bone to pick with those people.

Internet Explorer 6, which born in the summer of 2001, and still exists as a force, albeit a shrinking force, in the world of website design. There have been three new versions of Internet Explorer released in this nine years since.

That’s my history lesson. Read more

There are great things about being “just another developer”. You never burn bridges, your job is stable and respectable, your coworkers and bosses like you or are, at worse, indifferent to you beyond the work you do. Being just another developer is the best thing you can be if you’re interested in a long term, stable commitment with minimal controversy and stress.

And it is totally not for me. Read more

This debate isn’t new, this discussion isn’t new and I won’t pretend it is. The argument between bug and feature has spawned a lot of opinions from a lot of people who want to simplify the question.

Why does it matter? Because how we communicate internally matters a great deal.

Features: 

Features are things we haven’t tried before. Completely new code and functionality. It’s not hard to define, if you’re going to create whole new methods to accomplish it, it’s probably (but maybe not always) a feature.

Why it matters? Read more

Please click on the FHD tag to see all parts in this series.

We interrupt your regularly scheduled program to explain what this is. If you feel the information expressed in this interlude is incorrect, you probably won’t enjoy the rest of the series either.

My opinions are all based around the concept that no portion of software development is contained within its own bubble. Every piece must be interconnected or communications breakdowns will always occur. I won’t bend on that point, and I won’t deviate from it. There may be other and even better ways to keep things flowing, but they must flow naturally. Read more

Before reading part 1, you might want to check out the Finding Harmony in Development Primer.

Warning: All of the following statements, along with the additional entries I’ll make on this topic, are based on personal experience only. While experiences may vary drastically, this is my viewpoint on how development teams can be organized in a manner that will provide the best results and cause the least amount of friction. Opposing opinions are extremely welcomed. This is the first part of a multi-part series.

A development team consists of many parts, and part 1 of this series is going to be dedicated to defining those parts and  talking about their traditional functions. The next section will focus on altering those traditional functions to fit more inline with my viewpoints on the proper structure. In the third part we’ll talk about creating a frictionless transition from the traditional to the non-traditional.

Sometimes multiple parts of these functions will be performed by a single entity, in these cases treat them as two distinct job descriptions being performed simultaneously.

Now, the functions of a software team, in the order their responsibilities will be covered is: Read more

I’m setting forward a few goals I have for the next two months and hoping to kick the new year off right.

Get Prometheus.js to 1.0

This is huge. I will do this one.

Learn Python

#BecauseICan

Convert my Blogs to CppCMS

I’ve been wanting to go custom on this blog, and if I do, why not add CppCMS to my toolbox.

It should give me something unique to write about.

Besides, I’ve always wanted to push up a git commit to the effect of “Fixing that annoying segfault when a user double clicks post”.

Seriously, nothing on the web is double click, just stop it.

Get Prometheus.py to 1.0

Here’s hoping.

I posted yesterday about the thrill of having to get something in a hurry and as a couple of commenters rightfully pointed out, there is a dark underside to that situation. Namely technical debt.

Technical debt takes a lot of forms, from “well, just install it locally” solutions when something goes wrong with deploy, to code that you know just isn’t what it should be, but it’s quick.

We almost never get to go back and clean up technical debt, instead it just keeps accumulating. Like real debt the longer it sits the more interest it builds up as other pieces of your application come to rely on that badly formed code.

There are a few ways to approach the technical debt scenario, but rest assured that if you don’t clean it up you will regret it eventually. Read more