Articles — Page 4
Below is a collection of assorted writings, a lot of them are from my old blog, "Absolutely No Machete Juggling." Most of the posts are about technology and programming, but odds are you landed here because I once wrote a very long post about Star Wars and it blew up like the second Death Star.
Finding High-Impact Areas for Refactoring
At Rally, we’ve stayed committed for the last 7 years to never telling the business that the product has to halt active development to pay down technical debt. For us, the “big rewrite in the sky” has always been off the table. Instead, we prefer to incrementally refactor and improve the existing elements of the codebase, gradually getting it to where we want it to be without ever halting feature development completely.
Avoiding The Big Design Interview Question
There is one common type of question that I think sets up both the candidate and the interviewer for failure. I’ve seen it asked by my interviewers, my co-interviewers, and even by me. The question takes this format:
You Have To Buy It Twice Before It’s Cheap
One of the most common sources of tension between product owners and developers is when product owners are surprised at how high an estimate for a story might be. Usually this tension is easy to resolve by reiterating that the product owners really have no concept of how much something should cost. However, there is one scenario I see over and over again: when a product owner protests the estimate of a story because it seems, to the PO, like it’s simply re-using an aspect of the system somewhere else.
Units are Not Classes: Improving Unit Testing By Removing Artificial Boundaries
Many developers think of unit tests as tests that test a single class. In fact, I myself once thought this way. If I wanted to write unit tests for a two-class system in which a class used another class, I’d write two unit tests. After all, if I created instances of both classes in my test, that wouldn’t really be a unit test, would it?
My Personal 3 Pillars of Job Satisfaction
As I grow through my career as a software developer, I have tried to remain aware of what makes me happy or unhappy at a job. What I decided was that there were three factors in job satisfaction, so I found myself amazed that someone else had posted something similar: Alan Skorkin explains his Three Pillars of Job Satisfaction.
Enhancement vs. Defect: More Than Pedantry
Change is inevitable in the world of software. In fact, the need for change and the related need to adapt to change are the driving forces behind the agile movement. Requests for change generally come in one of two main forms: enhancements and defects. A defect means “the software isn’t working the way it says it will”, whereas an enhancement basically means “the software isn’t working the way the customer wants.”
5 Ways To Hose Your Estimates
Everyone knows the drill with Agile: the developers put estimates on stories, and those estimates are used to plan releases. Of course, some releases go awry, with the engineering team delivering far fewer completed stories than expected. When this happens, people start to ask “why are our estimates so inaccurate?” What many don’t realize, however, is that this is the wrong question. Estimates don’t need to be accurate, they need to be consistent.