project management

The most dangerous word in software development

I think this article – The Most Dangerous Word In Software Development – hits the nail on the head.

“Just” implies that all of the thinking behind a feature or system has been done. Even worse, it implies that all of the decisions that will have to be made in the course of development have already been discovered—and that’s never the case.

Every time somebody asks for “just” this little thing or that little thing, I ask them to “just describe it”, or “just answer a few questions”, or “just pay for it”. Somehow, it never turns up as easy and simple in the opposite direction.

Products Over Projects

Martin Fowler has an excellent article on the “Products Over Projects” subject. It depicts the differences of both, with advantages and disadvantages, especially in areas like funding, team management, and iterations.

It’s a great read for anybody involved in software development, product and project management.

Seven Reasons IT Projects Fail

While reading through “Seven Reasons IT Projects Fail“, I came across an interesting statistic (source):

By categorizing documented causes of IT project failure, a majority—54 percent—are attributed to project management. Surprisingly to some, technical challenges are the least-cited factor at 3 percent.

For me, this is just a confirmation of the gut feeling I had for years. It doesn’t really matter which technology stack you are using for your project. The reasons for success or failure are usually somewhere else.

The article lists the following seven reasons for IT projects failure:

Poor Project Planning and Direction
Insufficient Communication
Ineffective Management
Failure to Align With Constituents and Stakeholders
Ineffective Involvement of Executive Management
Lack of Soft Skills or the Ability to Adapt
Poor or Missing Methodology and Tools

SWAG estimations

Well, I didn’t know that I was a practitioner of SWAG estimations …

Scientific wild-ass guess (SWAG) is American slang meaning a rough estimate made by an expert in the field, based on experience and intuition. It is similar to the slang word guesstimate, a portmanteau of guess and estimate.

GitFlow considered harmful, and how we do it

I came across this rather strongly opinionated blog post – GitFlow considered harmful, and I have to say that I mostly agree with it.

In our company, we use a similar approach to the Anti-gitflow, but with even more simplicity. This is one particular thing I like so much about git is that each person, team, or company can pick the workflow that suits them best.

Just to give you a little bit of context, we have a rather small development team (under 10 people), but we do a large number of projects. All our projects are web-based, varying from small and simple websites (static HTML), through more complex WordPress sites (multilingual, e-commerce, etc), to business applications like CRMs. Each project is done by several developers at a time and can later on be passed on to other developers, often much later (another iteration after several month). Each developer is working on a number of projects at a time. And we do very fast-paced development, often deploying multiple versions per day. Given the nature of the projects and the development pace, we don’t ever really rollback. Rollback is just another step (version) forward. And we don’t have long and complex roadmaps in terms of which features will be released in which version. It’s more of a constant review of what’s pending, what needs which resources, and what we can do right now. (It’s far from ideal project management, but it somehow works for us. If you think you can do better, send me your CV or LinkedIn profile, and we’ll talk.)

In our case, we do the following:

We have one eternal branch, and we call it master.
The master branch is always stable and deployable. Even though we don’t really deploy it directly.
Nobody is allowed to commit directly to the master branch. Initially it was just an agreed convention, but because people make mistakes, we now have this rule enforced with the technology. Both BitBucket and GitHub support protected branches. BitBucket, in my opinion, does it much better.
All new features, fixes, and improvements are developed in separate “feature” branches. Most of these are branched off the master. For large chunks of work, we can create a feature branch, and then introduce incremental changes to it via sub-feature branches, branched off the feature one. This allows for easier code reviews – looking at a smaller set of changes, rather than a giant branch when it’s ready to be merged.
We do code review on everything. The strongly suggested rule is that at least two other developers review the code before it is merged. But sometimes, this is ignored, because either the changes are small and insignificant (CSS tweaks or content typos), or we are really in a hurry (we’ll review the changes later). But whatever the case is, nobody is allowed to merge their own pull requests. That is set in stone. This guarantees that at least one other person looked at the changes before they were merged in.
We tag new versions only on the master branch.
We use semantic versioning for our tags.
We don’t deploy branches. We deploy tags. This helps with preventing untested/unexpected changes sneaking in between the review of the branch and the deployment.

The above process suits us pretty well.