Collaborate during installation development – Installation development today is becoming more of a team sport where all developers can participate. There isn’t as much of a need for specialist in Agile development. You may have people that are more experienced in certain areas than others, of course, but in Agile everybody rolls up their sleeves and implements features. It also means all developers often participate in developing parts of the installer.
I had a reaction the moment I read this but I wanted to pause a bit before I shared my thoughts. First a little background on my world view. From 1996 to 2005, I experienced that most developers don't want to touch installs with a 10' pole. Back in 2005-2006, I participated in an attempt to make developers responsible for setup development. It ended very, very, very poorly. It was so bad that I quit the company and moved on. For the next couple of years I would read blog posts from the likes of various MSFT employees talking about Agile in context of Setup Democratization and I would just bristle at the thought as I remember just how bad it had ended.
After a couple of years I returned to that company in 2008 and after 6 months or so I started down the path of attempting democratization again. This time around we had better tools, better strategies and slightly better attitudes from developers. You can read more about this attempt here. Things went well, very well.
Ok, back to InstallShield's assertion from above. First, I question how common it is for installation development to be a team sport. I'm guessing they have market research that I don't because in my experience very few people do this. Second, I really disagree that specialists aren't needed. Deployment engineering and MSI / InstallShield are domains that can really bite you if you don't have extensive training and experience. A specialist is required on small projects to ensure quality and on very large projects an architect with deployment experience is desirable. Someone has to be responsible for defining and enforcing the strategy while delegating the work.
Now InstallShield no doubt sees the Agile buzzword has an opportunity to, well, sell more licenses.
There are several problems with this in my opinion. First is the cost of InstallShield. $2000 a seat is one thing when you are talking about a specialized tool for a handful of developers but when you start scaling that out to include all kinds of things such as stand alone build licenses, floating licenses, collaboration and so on it's no unusual for a mid sized team to get quotes of nearly $100,000. That's crazy.
Second is DRM. It's crazy to drop that kind of money and then be treated like a criminal. Maybe I'm a little extra jaded on this one because our development networks aren't connected to the internet and activation is a really big pain for us.
Third is InstallShield's DTD XML project format does not support branching and merging in a meaningful way. When I designed IsWiX a lot of attention was paid to creating XML could easily be developed on multiple branches and then merged back together without conflict. We use multi site base Clear Case and this is a very big deal to us. A little while back I looked at the version tree of a .wxs file and I was part horrified as to just how many branches there were and part elated in the knowledge that through all this it had magically worked without any developers ever reporting any issues.
Finally InstallShield has too much of a learning curve. An ideal tool provides an easy button abstraction while allowing for under the cover tweaking off all the buttons and switches. With IsWiX and WiX I get this. With InstallShield and InstallShield Collaboration I don't.
Now this isn't to say that InstallShield doesn't have a part to play. Frankly, I couldn't easily do what I do today without at least a few licenses of InstallShield. Perhaps in very large shops like Microsoft you can justify creating extensive external UI's, bootstrappers and chainers such as seen in Microsoft Office and Visual Studio but that just isn't an option for many companies. Conversly, I couldn't easily do massively scaled Agile development without WiX and IsWiX either.
No comments:
Post a Comment