One of the things that I try and do to further my personal development is to read at least one new business or technical book every month. About 6 months ago, I read To Sell is Human: The Surprising Truth About moving Others. I didn’t realize it at the time, but this was the most useful book I read in 2013. Basically, the premise of the book is that most people are in the business of sales; or at least persuasion. Your job may not be to get people to sign on the dotted line, but most knowledge worker professions are about convincing people of something. That’s certainly true about project kickoffs and architecture meetings. The whole purpose of that kind of meeting is to come up with a plan, get people invested in the plan and start the project off in a positive direction.
One of my personal project that started off as a thought experiment is slowly turning into reality. One of the ideas was to see what would happen if I turned up all the best practices to 11 and see what happened. The other part of it was that it was an excuse to use some technologies that I wasn’t that familiar with and learn something new. There were a couple of surprises, some of them very pleasant. Among them was how much starting load and performance testing early impacted the architecture of the project.
Being able to do multiple concurrent tasks for a story is the holy grail of agile development. It may not be a myth, but the amount and benefit of it has definitely been over sold. One of the consistent things that I hear that didn’t work well in sprints is that people complain that “this task forced me to rework that task, and it cost time”. This seems to happen most commonly by development changing test plans. However, I’ve heard it from people in pretty much each role at one time or another. Occasionally, I’ve been the one saying it too.
It’s too easy to just say the usual platitudes, “mythical man month”, “can’t produce a baby in one month…”. Blah, blah, blah who really cares? That’s been discussed a lot and no real answers have ever come up. The more interesting question is why do we keep buying into the idea that tasks are completely independent and can be done in parallel? For that matter, why do we think the same thing about stories also? If we start to understand why we think the tasks are independent of each other, perhaps that can provide clues about why this occasionally breaks down.
I had an incident last week where another developer accused me of applying a double standard to contributions on a project. The root cause of the misunderstanding was that he was looking at the unit test that he copied from the other developer, while I was doing a code review of the code he submitted. That got me thinking about code reviews versus unit tests.
Ultimately, it comes down to the quality of the code review and the quality of the unit tests. A lousy code review is waste of time for all parties and is less effective than good unit tests. The reverse is also true, a good code review beats poor unit tests.
I got asked recently about the role of architecture in agile development. Basically, the question boils down to some variation of “Is there a place for architecture in agile development?” This is a common and mostly misunderstood question. It seems like it gets asked on every project. It’s based on a faulty assumption: that architecture is something that is stand alone, that can be bolted on to a project.
To talk about agile architecture, you first need to understand what architecture is. Once you know what architecture is, and what it isn’t, the question changes to “How can you do good architecture in agile development?”
I just went to a training class, the first formal training class that I’ve gone to in years. Advanced Distributed Systems Design using SOA & DDD
To say my mind was blown is an understatement. It’s the entire contents for a semester long class in system architecture condensed into a five day span. It was the equivalent of trying to drink from the fire hose, far to much, far too fast to really take it all in.
Git is a great cross platform version control system. However, for windows users it’s got a really steep learning curve, especially when resolving merge conflicts. Working with some people that are just starting to use git, I see a lot of files getting checked back in with the merge markers like “<<<<<<< HEAD” still in the files.
In most compiled languages, leaving that stuff in the source, kind of breaks things. So there should be a way to let my more graphically oriented peers deal with the merges and inevitable conflicts more gracefully. P4merge seemed like it was the most highly thought of graphical merge tools among the team, so setting that up for merges and diffs would probably be easiest.
One of the arguments that I see a lot in favor of Test Driven Development is that it helps deliver higher quality software more quickly. The more I projects I take part in or observe, I realize that this is only half true, and less than half true for Agile projects. I’m not saying that TDD has no place in Agile projects, just that it has a very specific place and time.
One of the causes of death march project is poor story definition. Whether you call them stories, features, tasks, items or whatever, defining good stories is essential for success.
The ACID principle from database design applies to stories as well as databases. Atomicity, Consistency, Isolation and Durability. These principles apply to story design as much as they do to anything else.
After 20 years off earning my daily bread writing software, it’s still thrilling to start a new project. That feeling of hope, knowing that this time we’ll do it right rather than cut corners and choose good over expedient. Every new beginning makes me think of what should happen, and reflect a little on what makes good work. That gets me thinking about what makes quality software.
One of the most important things in any endeavor is solid fundamentals. Whether it’s playing a sport or writing software, the basics matter. Always.
Scott's Thoughts 