MVP stands for (in this article) Minimum Viable Product. It’s not an Agile concept. It’s not even a software-specific concept, though it’s certainly easier to do with software, since upgrading software is usually easier than upgrading hardware. The concept is simple: Instead of building every feature under the sun into your product then releasing it, build the least you think people will buy and release that, following up with more feature-rich versions. There are several good reasons to do this. Read on…
When I phone screen a Java candidate, I ask just two technical questions to assess their competency and give me a feel for where they are on the scale of “Heads-down coder” to “Java Software Engineer”. In general, I try not to discount any candidate on just one factor, because we all have different weaknesses and strengths. That’s why I consider these assessment questions instead of must-haves.
This is especially true of SQL questions in interviews. I am way more interested in their thought process and how they come up with an SQL query than I am the query they respond with. I’m not testing whether they have SQL syntax memories; I’m testing whether they understand how relational data can be joined and aggregated and filtered to produce the desired results.
I heard a CEO say the other day that “Charity is not a business model”. I’m not so sure that’s the case, but it got me thinking. And researching. It turns out that companies (and their executives) are not legally bound to maximize shareholder profits, as many people (including myself, until now) think. Businesses can form to, and focus on, maximize any collection criteria they want.
Performance evaluations and performance management are areas I disagree with many Agile coaches’ opinions on. “Popular opinion” is that you don’t evaluate individual team members at all. You only evaluate the team as a whole. They maintain that team members are self-motivated and will do their best to support their team. They also feel that evaluating individuals on the team could lead to stratification, and all team members should be treated equal and be at the same level. What I propose is to evaluate individuals, but to emphasize team support and commitment in the evaluation.
“Only the madman is absolutely sure.” ― Robert Anton Wilson, Masks of the Illuminati
Nothing in this world is completely black or white, good or bad. The human brain likes to categorize things. Put things in neat little buckets, so it can think of groups of things, and assume all things in that bucket have certain attributes. When that happens during a decision-making process, though, you’re throwing away information before assessing its value. As soon as you feel you’ve categorized it you let go of the information that went into that categorization. Incomplete information is the enemy of sound decision-making. Sometimes you need to make snap judgements when timing is of the essence, but even then it should be a first approximation, to be re-evaluated later. Read on…
Since I’m in Boston, we have a lot of snow to deal with this winter. The other day I was clearing snow off my roof with a roof rake, and after about an hour for some reason it started pulling to the left when I pulled straight down. I started to compensate by pulling the roof rake more to the right to compensate, but that didn’t really help much. After finally getting frustrated enough to pull the roof rake down and look at it, I saw that one of the support brackets was no longer screwed to the rake, so the blade was unsupported on that side. That’s why the rake was pulling to the left. Had I looked at the rake as soon as I noticed the problem, I would have saved a lot of frustration, and possible permanent damage to the roof rake. I fee we do the same thing with our software tools a lot.
Very often I’ve seen software where the usual reaction to compilation warnings is to tell the compiler to ignore them. There are times when this is appropriate. My favorite example of this is with Java Generics, where it’s very hard to get around some of the warnings for things that you and I know are perfectly safe. Most of the time, though, compiler warnings are indicating a moderate to serious problem, or at least an area where the program might not be doing what you think it is. Eliminating those warnings is an excellent collaborative activity, because we all have experience with different software issues.
So the next time you feel tempted to “ignore the Check Engine” light, spend some time finding out if there’s a more elegant solution than putting tape over it.