Sitting in unnecessary meetings sucks. You know what I’m talking about: A lot of people crammed into one room, half of whom have no business with the discussion. The other half are responsible for the topic, but didn’t bother preparing for the discussion. So why are all these people sitting together? Let’s examine this from an unusual angle…
Click to continue…
Desktop application development is traditionally done in waterfall development mode. Specifications and requirements are gathered over a period of months before being unleashed upon a “pool” of developers for implementation. Development times run into thousands of man days after which a “beta” product is released to the QA team (or perhaps some very brave customers). After another thousand days of bugfixing, you slap a product version onto a shrink wrapped box, burn the CD-ROM and ship.
While it may be hard to believe, this is how the majority of software development has been done for almost half-a-century. The older the company, the better the chance they follow this exact release cycle. There are annual budget meetings to determine which departments and projects will gain the largest developer pools. It’s excruciating to watch these behemoths try to introduce agile into such an environment and I believe budgets are toxic to agile development!
Click to continue…
Starting a job with a running system and real users is a nice “problem” to have but it presents some unique challenges as well. Especially if server monitoring isn’t robust and there are absolutely zero automated tests. Without these two critical components, you’re both operating and developing completely blind.
Without monitoring, server changes can’t be analyzed to see you’ve really made things better (or even worse). And without testing, every commit you make is a risk to the running site.
Click to continue…
Kevin Parker
This is an interview with Kevin Parker (@kevinparkerusa) about DevOps
How do you see agile affecting application development and delivery?
The biggest impact is that application development teams are using agile to speed up their delivery of software changes and updates. This makes the developers happy as they can get through requests faster. However, releasing that software out to the organisation is different: small teams are responsible for their own releases, while larger organisations have dedicated staff that handle getting software out to the business.
Whatever size you are, the increasing number of releases will have an impact on the overall process. One customer I spoke to recently has taken up agile, and gone from 50 releases per year up to 350. That is a huge increase. While the amount of code might be smaller, the change procedure will be the same, and that puts pressure on the overall application delivery process and the staff who release the software. This introduces the risk of there being undiscovered errors in the release. And that might mean production outages.
Click to continue…
Today was a great day. I helped import our entire “roadmap” of functional requirements from an Excel spreadsheet into Pivotal Tracker. Even though we allocated almost a half-day to accomplish this, it was done in less than two hours (including in-depth descriptions and backgrounds on many features I hadn’t yet seen).
The product manager’s eyes lit up when I showed him how priorities were set (drag & drop, top story rules) and how easy it was to add screenshots to stories (again drag & drop). He spoke often about the pain that spreadsheet caused him and the entire team. Ironically enough, just before we were to sit down and do the migration, he realized he’d lost the changes to the spreadsheet made last week in the team meeting! A fitting farewell from an overly abused project management tool.
Click to continue…
This is a guest post by Brian Doll, Application Performance Engineer at New Relic
Six seconds can be an excruciatingly long time to wait for a single web page to load. Why does it take so long? Let’s take a look at each step of the timeline and see how we can make it faster.
Page load timeline.
Click to continue…
Consider the following: People are complicated and companies are run by a lot of people. A relationship between two people is complicated. Relationships between companies? Well, you see where I’m going.
Outsource a software development project requiring 10 developers, an on-site team of 3 managers and 4 developers, involving a total of 4 external companies. Surprised that the shipped product is more complicated than you originally planned? You shouldn’t be.
Click to continue…
One of the most challenging things about introducing Agile in the workplace is that it’s not very widespread. People have heard mixed reviews about it’s implementations, and are hesitant to exchange the known (no matter how bad it may be), for the unknown. More and more companies, however, are adopting Scrum for their project management. The “scrum flu” usually starts in one department, and, if implemented successfully, begins spreading throughout the rest of the company. Nevertheless, kicking off any form of Agile Development for a team with no prior experience in Scrum, Kanban or even XP, has to be done with thoughtful deliberation since a poorly managed migration can quickly result in disillusionment.
Here are a few technical steps which have to be made before you change project management styles.
Click to continue…
Scrum defines a set of required meetings: Sprint Planning, Daily Scrum, Scrum Review, and Scrum Retrospective. Additionally, there might be a Scrum of Scrums, if you’re running multiple Scrum teams in parallel. If you’re doing two week sprints you spend at least half-a-day per week in Scrum meetings. Isn’t that a lot of additional overhead?
Click to continue…
Click to continue…
It’s been a while since I talked about how we develop and deploy software at my current job. It’s come a long way from the “Good Ole Days”, when cowboy coders manually FTP’d their changes to the master server and rsync came along 5 minutes later to replicate the changes to the slaves *shudder*. Keep reading below for the details.
Click to continue…
