Looking back, nothing has changed.

The other day I was reading that Martin Fowler will be visiting Austin giving a presentation on “What Agile really means to the future of software development”.

I’m sure Martin is better then most ( he did after all sign off on a Continuous Integration book written by a good friend of mine – Paul Duvall ) but most evangelists and developers that I’ve met think very little of setup.

This reminds me back to something that Bob Baker wrote over 10 years ago in the Official InstallShield for Windows Installer Developer’s Guide book.

“The main problem that is faced by the setup developer is that he creation of the installation for an application is normally left to the last minute just before the product has to ship. This is because setup is not considered part of the development process.”

It’s now the year 2010 and this is still true now more then ever. I’ve been doing setup development since 1997 and the one thing that is a near constant is that developer always treat setup related tasks and the setup developer himself as second class citizens. They assume that because your working on the install that you must be a development flunky. This is probably because that’s the way it’s been everywhere else they have ever worked.

Frankly it’s really annoying. Seriously, just how many times can you take some new developer coming into your office, looking at the setup problem domain from 50,000 feet, claiming that it’s easy in a condescending tone and then refusing to provide meaningful participation in solving the problem? BTW, can you get this done by tonight’s build? That would be grrrrreaaaaaat.

These guys can talk a mean talk about Agile, Scrum, Lean, TDD, IoC, MVVM, ASP.NET MVC, Separation of Concerns, Single Responsibility ( and so on and so on ) but they always wait until the last second to come to you to get their install done and God forbid you see a problem with their design that effects setup because frankly they just won’t care because ‘it’s already done; this needs to ship next week’. If you try to explain to them that they should learn setup and include it in their Agile and Lean believes they suddenly become very disinterested.

Since your bothering to read this I’ll assume your a setup guy and have already witnessed this. But let’s assume for a moment that your not and you don’t believe me. To date, 500,000 questions have been asked on StackOverflow. Here are are the top 10 tags in popularity:

c# 61927
java 34410
.net 32759
asp.net 28696
php 27893
javascript 25159
c++ 24402
jquery 18771
python 17964
iphone 16413

This is a total of 288,394 question or apx 58% of the total. Now lets see how many questions have been asked about setup:

msi 469
wix 439
installshield 142
installaware 5
wise 15
installer 763
windows-instaler 357
install 231

This represents a total of 2421 questions or 0.5% of the total. Truly sad IMO.

Then there is a dearth of interest at code camps and conferences. For example, someone recently told me that at a recent Microsoft PDC they attended a deployment focus group. He indicated that it looks like they had swag for 12 people and that 4 people actually showed up.

Think about that. Of all the thousands of developers who attended PDC, only 2 of them had enough of an interest in setup to attend a focus group.

However, there is a bright side: Setup isn’t going away. Projects of all sizes continue to need deployment solutions that work. Yes, this is a niche field with little respect, but there is some real good money to be made if you are willing to commit yourself to learning everything possible and become the world beater that can make things happen. You will have so little competition from your peers because they don’t have a clue just how important setup actually is.

16 thoughts on “Looking back, nothing has changed.

  1. Kent D

    Please don't change a thing. I make my living cleaning up details that every Setup Developer would fix if they had a bit more time. The reality is that they have a Project Manager asking hourly "are you done yet", Testers who provide valued feedback like "works on my machine", and two or three environments that as hard as you work to get things right may still run into compatibility problems.
    A Deployment Engineer like myself say's before I deploy this to 20,000 PC's I'm going to test it, and with my wrapper change the install to be compatible with standards at this enterprise. This how I sell my services to the Desktop engineering team. I've been part of big and small deployments, sometimes finding glaring errors, and other times just changing things because "that's the way we do things here".

  2. Anonymous

    It's not that big different to be a setup tester. Other test or dev come to you and say "we have created this cool feature that takes this dependencies" and they expect you to test it on a complete test matrix of configurations and create autoamtion over the day.

  3. Vijay Kumar

    Yes… you are bang on target. I have been facing this second rated citizenship treatment since long. Well recently in my current work I have generated some sort of urgency and respect for the setup/installer work which eventually fetched me the first spot award from the entire developers group but the catch is here that the award citation clearly mentioned that "thou the work was meant for developer and got delivered by a build/release/setup guy, so was this recognition conferred." 🙂
    It was really boosting to read your last paragraph. Thanks.

  4. Jean

    I agree as well with your comments, they are so on target.
    I have implemented CI and somewhat gotten the focus on setup during planning, but still struggle with respect from my peers.. I have a double whammy…. being a female and an install developer.
    🙂

  5. Julian

    We're always focused on the doing and not the delivering. True, honest agile projects should attempt collapse the entire project lifecycle into the sprint/timebox/iteration – and that includes deployment and packaging concerns.

  6. Neil Sleightholm

    I totally agree, I spent most of last week working on a setup that wasn't even considered a task on the project plan!

    May be setup developers ask less questions because they are so much cleverer than other developers 🙂

  7. alkeiser

    If I could "upvote" this I would.
    I've been trying for years to get the setup/deployment to be treated just like all other development and included as part of the application's lifecycle.
    Hasn't happened yet but neither have I given up the fight.

  8. Christopher Painter

    Since you clearly understood what I was getting at, there wasn't any miscommunication was there? Either way I don't really care about your opinion unless you have something interesting to add.

  9. Andrew

    Hello Christopher,
    I feel the same way, I would like to thank you for sharing your thoughts on this here, and as a response to my questions on this in the Flexera Forum. I am hoping that more people would share their thoughts on this either here on on that forum thread, as I am studying this subject in order to offer practical solutions. I invite anyone to stay in touch as I would like to hear more thoughts and share mine.

  10. Anonymous

    Another blow to Installs Developer, I was recently reorganized to the test automation team as described so we could "leverage the synergies between install developer and Test automation." I truly don’t get it, not to knock QA and their function. I don’t see this. We use different tools, language and have different purpose. It all seems idiotic to me. I guess until software developers and managers decide so to show respect for the setup developer we will have to deal with this culture of lack of respect.

  11. Yan Sklyarenko

    I've managed to attract attention to the setup development and the time necessary to create the installation in the company I work for. And it is now considered while planning the scope and estimating the timelines. And this makes me happy! 🙂

  12. Nat Pryce

    I totally agree! In our book, "Growing Object-Oriented Software, Guided by Tests", we recommend automating the system's packaging and deployment at the earliest opportunity and then automatically exercising from continuous integration to kick off the system tests. Addressing it early means that packaging technologies that work poorly with automated testing (e.g. require manual packaging or manual deployment) get kicked out of the project before too much effort has been spent on them.

Comments are closed.