This story goes back at least a decade, when I was first approached by a PHB with a question “How big servers are we going to need to buy for our production deployment”. The new and shiny system we have been building was nine months from production rollout and apparently the company had promised to deliver the whole solution, including hardware. Oh boy, was I in trouble.
The problem I had was that I knew were I needed to go, but instead of taking small steps, I kept trying to take one big leap at once. Which brings me to the analogy of Agile to good programming habits (and TDD would be one of them). One of the advantages in Agile development that I really like is the small steps (iteration) we do in order to reach our goal.
In this article we answer a common query about Scrum and Kanban boards: what columns should be used for tracking the progress of work items?
The gig that was suppose to be a couple of weeks long was quickly turning into a perpetual job. Soon I learned that what I was working with was a system that had a lot of bugs, but no one was willing to admit that. Eventually, frustrated by the fact that this system seemed to have a new bug every day, I asked for the specs so that I could create a test plan. That’s when I found out the worse news of all about this system: Lost Specifications.
One side of my news feed showcases how we are innovating with technology in so many new ways, and the other side just tells how screwed we are. Which is it? Are we innovating or are we drowning in big problems?
Agile teams embracing TDD thought-process to design and implement their product features have realized significant improvements in code and design quality. Still waiting and thinking about TDD?
Python has a number of different concurrency constructs such as threading, queues and multiprocessing. The threading module used to be the primary way of accomplishing concurrency. Unfortunately, threads in Python are severely limited by the Global Interpreter Lock (GIL) which causes all your threads to run on the same core.
This article deals with different approaches to load multiple versions of the same class.
This article describes an approach for creating live documentation for Java projects. One of the easiest way is to use a BDD framework - but which one? Hopefully this article will answer your questions...
In this post we will explain how we can move to shared responsibility by focusing away from roles in Scrum.
Code metrics are a conversation starter. Metrics are a great way to start the conversation that says, “Hey, I notice there may be a problem here, what’s up?” In this post, I’ll go through a few cases where I’ve used metrics effectively in concrete ways. This is personal; each case is different and your conversations will vary.
Java 8 parallel streams are dangerous in a multi-threaded environment. They share common thread pool so one task may block other, unrelated, parallel tasks.
To fully realize predictability, progress visibility and collaboration through Agile, you need separate Agile systems to manage responsibilities and accountabilities that are different for each role.
Described by Elisabeth Hendrickson as originating with the misguided belief that “testers test, programmers code, and the separation of the two disciplines is important“, the traditional segregation of development and testing into separate phases has disastrous consequences for product quality.
One bad habit that permeates the industry is fellow developers arguing about how code is written. Although their hearts are in the right place, in most cases their focus may need adjustment. The late author Zig Ziglar was known to say "Be firm on principle but flexible on method." This is an excellent approach not only to life but programming.
I would have said “Test Driven Development” but I want to make it clear that what I’m talking about is writing test first, or at least simultaneous to writing the code. Not sometime after, even if that after is immediately after.
A great development manager once said, "It's just software." That simple statement tells a much larger story. Software development for most companies is all about time and money. Most requests can be satisfied but developers have a tendency to rebut with "no" when they believe the work is too difficult, requires extensive time, or for a variety of other concerns.
Github’s pull requests are a terrific tool for collaborating on open-source projects. I get one or two a week on average for my projects, and I love it. The UI is very clean – you get to see exactly the changes, the full branch if you’d like, even the Travis CI integration is working checking that the branch still passes your tests.
This article is the third part of the Cloud Delivery Blueprints series. It discusses how to go from no cloud infrastructure and no continuous integration set up to having a functioning Deployment Pipeline in Amazon Web Services. It discusses high level topics while also providing a reference implementation so it’s easy to follow along with
By applying a faulty implementation of the well-known Quicksort algorithm, we show how to find bugs faster. The method is based on reducing the input so that the smaller input still trigger the fault while even smaller doesn't.