A "README" about Joshua.
In the spirit of this and this, here's my "README".
www.unblinking.io - A quick list of my public facing projects.
All of my public facing source code repositories are available under my GitHub organization page for unblinking I/O. I only keep private repositories under my GitHub user account.
Customer service and software development go together.
I once worked as a first-party bill collector. In debt collection, you are either first-party or third-party. First-party collection is when you collect on your own debts. Third-party collection is collecting on someone else's debts. Third-party debt collectors have bad reputations for breaking the law and generally treating people horribly, maybe because they only want the money. When you are a first-party debt collector, you are not just collecting on an overdue debt, you are also interacting with your customer. Just because you are collecting on an overdue debt does not mean you forget about customer service. In fact, maintaining a high standard of customer service will probably increase your chances of collecting on the debt. The debt collector's goal is to assist the customer in repaying their debt.
One of my managers described the job as Customer Service Based Collections. It made a big impact on me at the time, and ever since I have tried to think of everything I do as Customer Service Based.
In the spirit of development processes such as Test Driven Development (TDD), maybe this would be called Customer Service Driven Development (CSDD).
Software development is more like creation, and less like construction. Terms and metaphors about software development that compare it with construction (e.g. build) can contribute to misunderstandings and unrealistic expectations.
Most work methodologies used during software development are going to require planning, but that planning can't just be timelines and due dates. Sometimes planning doesn't need timelines or due dates.
I'm not a sports expert, but I imagine that when professional sports players are preparing for a game their managers don't ask them to put too much effort into predicting exact timelines of how the game will play out and the exact final points total. Of course, there are people who plan things around the actual game play, like TV schedules, and they might want an estimate of how long the game will play out. But the players aren't responsible for making those estimates, and they aren't graded or valued based on how accurate those estimates turn out to be. The players prepare by doing things like getting their "head in the game", training, staying healthy and well rested, and minimizing stress. They lean on their teammates and competitors for advice, support, and motivation.
Trying to pin down exact timelines and points totals before the game starts is something a gambling bookie might focus on so that they can maximize their profits. In this way, the gambling bookie seems to have a lot in common with someone who seeks out exact timelines for a potential software project. But once again, the gambling bookie wouldn't ask the professional sports players on the team to make those estimates.
Software development is also like a road trip where you can know the car (mileage, speed etc), and the destination, but not the route. You have to start the road trip and then monitor progress before you can really make an estimate that has any value.
But IMHO, none of these metaphors are quite as good as the metaphor of artistic creation. How do professional creative artists plan their projects? Do they have battle tested methodologies that can be used in software planning? Yes. A web search for design methods will reveal some great results. One from Zurb is to Define, Ideate, Prototype, Build, and Analyze. John Chris Jones said of design methodology that "... it's not another way of doing design, you see, it's a way of doing what designers don't do at all." and he wanted to integrate design rationality with design intuition. He also said "New needs grow and old needs decay", which I feel fits with software development closely. As soon as the project starts, new needs begin growing that weren't apparent before, and old needs that estimates were based on begin to decay.
Software development projects can succeed as a partnership of creation if all parties involved can agree that it is a creative endeavor which requires a creative design methodology, and that it is not a linearly cumulative construction project.
I prefer a Kanban method over a Scrum method. Although both of these methods can work well together, lately my work requires more flexibility around things that I have no control over, such as changing due dates, project scope, and priorities.
Here are some of my favorite quotes that help steer my thoughts at times.
"… you have to say to yourself – 'I don’t know what I’m doing. We, as a field, don’t know what we’re doing. We don’t know what programming is, we don’t know what computing is, we don’t even know what a computer is.' And once you truly understand that, once you truly believe that – then you’re free, and you can think anything."
- Bret Victor - The Future of Programming
"Everything gets interesting at the edges."
- twit.tv This Week In Tech episode 681
“So convenient a thing to be a reasonable creature, since it enables one to find or make a reason for every thing one has a mind to do.”
- Benjamin Franklin