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…
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.
As a Software Engineer and as a geek, I face many tempations. One of them is “I can add this really cool feature while I’m in the code, and it will take hardly any extra time. It won’t impact any of my other work at all”. There are some very good reasons why you shouldn’t do it though, and why it’s an Agile anti-pattern. Read on…
When someone, especially new software developers or those still in college, asks me whether they should learn Java or C#/.NET, my normal answer is something like “They both do about the same thing, but Java will run on almost anything, and almost all the development tools are free. With C#/.NET you could pay hundreds for Visual Studio, and the programs will only run under Windows.
Microsoft has a long history seeing open source as the enemy, but has never had a problem stealing ideas from it. They even use marketing jargon that is directly opposite of reality. My favorite case of this is Microsoft Windows Services for UNIX, which is actually UNIX-like utilities you install on a Windows computer to give it UNIX-like functionality, not something you add to a UNIX box to help it communicate with Windows. In the past Microsoft has even called Linux a cancer. These days they’re singing a different tune, one that goes “We love open source“. We know what the motivation is. In the real world, business computing environments are of mixed architectures and operating systems. Everything needs to interoperate. They’re not going to dominate the server world like they do the desktop. But you know what? I don’t even mind that they don’t mean it as long as they act like they do. And they are.
Microsoft is opening up major parts of the .NET codebase to open source. They’re doing so under the MIT license, not a GNU license, and that makes sense. They’ve made major contributions to Linux in the past decade. There’s also now a community edition of Visual Studio so you can use it for learning and some projects for free, which is long overdue for them.
I’m a Linux lover, not a Microsoft hater. Any steps they take in the right direction are OK by me!
There are a lot of technology options out there. There are even a lot of free/open source technologies out there. So much so, that it’s tempting to install too much of it. Having too much technology can be just as bad as having too little, and “free” can become pretty costly. Obviously I’m not knocking free/open source, but the misapplication of it.
First and foremost, the more software/hardware you have, the more likely it is that some of it will have a bug. That’s just law of averages coupled with the fact that no significant software project is really bug-free.
Then there’s the maintenance effort. The more technology you have, the more effort needs to go into care and feeding of it. Also the more you have to learn about.
Lastly, just how Agile teaches us to delay decision-making and development to as late as possible, because that’s the point where we know the most about what’s needed, the more technology you put in place before you need it, the harder you make it to implement what you really need when you do.
Geeks and non-geeks alike should do their research when buying electronic devices to make sure they can actually do what they want, and don’t have unacceptable attributes. In this post I’ll give some examples, and some helpful guidelines.