- Details
- Written by: Jason Ross
In the everyday rush of work and family life it’s easy for personal projects to be neglected. That’s what happened to one of my web sites, which hadn’t been updated since 2010. It had been uploaded to a new web host and just left there, and was showing its age. I decided it was time to update it, and I thought I'd describe the process here.
- Details
- Written by: Jason Ross
Modern systems are fast. Very fast. So why is it that they seem so slow? Controls take too much time to be filled with their contents, web pages take too long to display, documents take ages to retrieve, and applications feel like they have to “think” for a while before they do anything. All running across ridiculously fast networks that somehow seem to run like they’re connected with pieces of damp string. What’s gone wrong?
- Details
- Written by: Jason Ross
Many developers that I’ve worked with seem to have an almost unhealthy obsession with the idea of “Information Radiators”- wall-mounted screens, coloured lights and displays in the office, showing successful or failing builds and deployments as well as general information about the system.
At first this may seem a little dramatic – isn’t it humiliating to have your failures publicized? Why does anyone else but you care whether your build fails? What benefits does this sort of thing give us?
- Details
- Written by: Jason Ross
In Eliminating Failed Deployments – Part 2 – Automate Your Obsession, one of the checks I suggested was:
Ensure all of the binary files have an appropriate version number; “1.0.0.0” is NOT an appropriate version number.
So, WHY isn’t 1.0.0.0, or anything like that, an appropriate version?
- Details
- Written by: Jason Ross
Conway’s Law states:
"Any organization that designs a system...will inevitably produce a design whose structure is a copy of the organization's communication structure."
It’s often paraphrased as the structure of software developed by an organization reflects the structure of that organization. What if this sort of reflection applies in other areas?
Read more: Programming - Should Your Code Structure Reflect The Data Structure?
- Details
- Written by: Jason Ross
A few years ago I was working in The City of London. The company I worked for had a very good development process – continuous integration, unit testing and several test environments before production (the sort of thing described in Eliminating Failed Deployments – Part 1 – Replication! Automation! Complication?). Environment-specific values were automatically inserted into configuration files and deployments were made by staff who weren’t developers.
With all that, you’d expect that deployments went perfectly, but they didn’t. We still had problems that weren’t always enough to warrant rolling back the deployment, but WERE enough to cause delays and the occasional frantic phone calls and debugging sessions.
One particular deployment faltered because the deployment didn’t update some permissions to match the other changes it had made. After you experience problems like this a few times, it’s easy to see how obsession can build up.
Read more: Eliminating Failed Deployments – Part 2 – Automate Your Obsession
- Details
- Written by: Jason Ross
Whatever development method you use, eventually your software will need to be deployed to your production environment.
It’s a scenario that occurs in every company with a software development team: the software is declared to be finished and ready to be deployed from development into production. The deployment scripts and installers are ready (if you’re not using installers then that’s a totally different set of problems), and there is an air of tension around the team responsible for the deployment. That air of tension is actually the first serious warning sign and you should take notice of it.
