One of the things that I see going by the wayside in most places is the bug triage process. The step of taking incoming issues and validating them and prioritizing them. It’s a real shame when that happens; both of those functions are important. Establishing the priority of the defect relative to the existing work is arguably the more important for delivering the most value per unit time. However, validating the issue is the single most useful thing that can be done. It provides two main benefits. First, it makes sure that the issue is ready to be worked, that it’s not going to waste the time of people downstream in the process trying to figure out what the problem is. Secondly, it’s the quality assurance on the quality insurance process.
Archives for category: Uncategorized
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 the things that I see when dealing with agile teams and new challenges is people being either unwilling or incapable of accepting the challenge. Of the two, unwilling is a lot worse than incapable. Dealing with teams that are unwilling to undertake a project, or are incapable to doing the project present special challenges. Part of the problem identifying what’s going in is that on the surface, unwilling presents itself as incapable.
An Enterprise service bus is a cool piece of technology designed to solve a specific problem. Basically, it’s and N to N multicast communication device. You can have a variable number of message senders and a variable number of message recipients. Decoupling the senders and receivers and decreasing the number of touch points in inter-service communication.
The downside of an enterprise service bus solution is that you need to make sure you have an ESB type problem. Like a lot of enterprise patterns such as CQRS, an ESB is great at solving it’s specific type of problem and truly horrible when it’s not applied to the right problem.
The SOLID principles have been kind of a cornerstone in software development for me. I think if the SOLID principles as part of the foundation of what makes good software. I kind of wonder about the fad for using closures now. Maybe I’m just an old crusty developer doing the equivalent of “you kids get off my lawn!” but it seems like closures are just another way of doing function pointers that made working in C/C++ such a pain in the butt.
This article http://arstechnica.com/information-technology/2012/09/should-i-continue-teaching-myself-how-to-code-or-should-i-go-pro/ started me thinking about closures in a different way. In a lot of ways a closure is all about inversion of control. They’re about passing around the logic to work on various sets of data. That’s pretty much the definition of inversion of control.
Although, I will admit that I’m not the greatest fan of the C# style of anonymous closures. I think that they tend to be over used, like all fashions. They have they’re place, but that place isn’t every place.
I think the case against closures is really about the Law of Demeter, the D in SOLID. The way that the law of demeter works is basically the transitive property of objects. “The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).”
Closures, particularly anonymous closures that access variables outside of their lexical scope increase the brittleness of software by breaking the law of Demeter, just for variables instead of objects. By creating super complex closures, we lose sight of what’s defined where and it’s easy to create errors that flat out wouldn’t happen with named closures instead. If you’re in C#, this is no big deal you get a compile error, but it adds hours of debugging time in an interpreted language like javascript. Basically, the closure function is making assumptions about what is defined in the outer lexical scope(s).
In the end, I think that the SOLID principles are still the fundamentals and should be followed as a default. Although, we should keep in mind other ideas, like closures that can help when appropriate. “Rules exist to make you think before you break them.”
Scott's Thoughts 