Don’t Baby Your Builds

In a conversation this week, one developer insisted that a special build machine should be built to assure that the build is always comes out the same.  My response: if your project is building differently on different machines, then you have a much deeper problem.

Advertisement

Incremental Development

I happened across this excellent and perfect depiction of incremental development.  The image addresses on of the key flaws in thinking that lead some agile projects to fail.  So let’s discuss a bit.

Source Management – 7 Rules

Those new to a source code management system tend to make a few predictable mistakes. These 7 rules are helpful to be learned right away and form a good practice from the beginning. I also have seen some experienced programmers who could benefit from following these rules.

Error-First Design in JSON/REST/AngularJS integration

You have heard about “mobile-first” when creating your UI, but there is something you should do before you start designing the UI:  you should design the error handling/display mechanism first.

9 Rules for Designing the Build

Every software product needs to be built, and the script to build it is as much part of the product as anything else.  Here are some guidelines around how to design the build script.

Improving the Code through Installation Manual Analysis

What can you learn from your install manual that can make your product better?  Below I outline a technique to work through an existing installation manual, and methodically find clues on how to make a software product better.

26 Hints for Agile Software Development

I collect nuggets of wisdom on various topics. Recently I have been going over the topic of Agile software development; what really matters?  Below is a list of 26 key principles to guide an agile software development team.

Don’t Suffer Poor Names

You know the problem: you write a method for one purpose and give it a name.  Later, it become useful for something else, or maybe you change it slightly to accommodate another use, or maybe some names change elsewhere making the current name obsolete.  You have all seen code where someone says that the name “is historical” or traditional.  This post is to say with conviction that that history is NOT interesting, and get rid of it.  Get a good IDE and change those names to be correct.

Trasparency Advantage

This is an example of some open source software that I had difficulty using and how to improve it.  A common principle is that of transparency: when something goes wrong, don’t hide it.  Don’t cover it up.  Don’t attempt to continue as if nothing happened.  Report it properly and immediately.  A simple explanation of the situation will help a lot.

Classic Date Drift Case Study

A waterfall project is required to predict dates that certain things will happen in the future.  There are usually many pieces of the project, each with their own date, and each dependent upon others.  No one can change a date without effecting others, and so a game of “chicken” ensues where people report dates they plan to complete and never hint there is a problem.  At the last possible minute they declare a change in date, and when you look at the history, you can easily conclude that they should have known ahead of time that the deadline was to be missed.  But everyone waits for someone else to change first.