As I have written more and more scripts, they have gotten larger, more complex, and, the expectations have increased dramatically. At first, my stuff was very, very simple. Run a scheduled task to remove temp files off web servers. Archive files. Recycle web app pools. Et cetera. Simple, discrete tasks. Now, some of my larger tasks involve provisioning web servers and rolling out production code, installing IIS, setting up complex applications, and, providing SCOM management capabilities. As I have shifted from smaller, one-liners, to, larger, very complex, production grade scripts, I have found thinking about them like software development projects, with the SDLC in mind, helps. However, these are scripts, not, code. I can't do complex testing, as you can with C# and VS. I can't do UML modeling and develop code-bases from early-stage designs in VS.
So, I was wondering, for developers, how do you handle this type of situation? Do you just keep it all straight in the back of your head? Do you use any sort of formal model on bigger projects (waterfall, Agile, etc). How do you guys handle the PM side of these coding/scripting projects? I have been looking for a good book on project management/SDLC framewok basics, but, the best I can find are MSCD/MSPD titles which only hint at this "bigger picture" or older, wisdom based literature, like Code Complete. I know scripting can easily be written off by devs and management duct tape development, but, I want to be more professional in my projects and was hoping folks might have some suggestions on things worth looking into. Articles? Books? Patterns? Anything I can use to help me transition from what would be the equivalent of a solution level developer (in VS) to an application and ultimately, an, enterprise level developer (in the development model) or scripter (in my little world).
Also, any tips on how others think through their projects would be greatly appreciated. I am essentially a one-man team when I write my scripts, even the big ones, because we have no buy in at even the grassroots level. Management likes that we can kill our annual renewal of InstallShield's license and the fact that PowerShell is a language most any professional developer can become competent in very quickly. That means we don't need to have the "Powershell" guru and project development and maintenance can be handled by most anyone. From this perspective, management is very interested in Powershell. It's simpler, cheaper, and, faster, than many alternatives such as InstallShield (which is expensive and requires licensing) or WIX. Plus, there is no need, for most people, to get into complex IDE's, etc They can just run PowerShell ISE, incorporate their own new piece of the puzzle, test on a development machine and move on to the next task at hand. One of our developers took the script base I had developed, and, in two weeks, created full-scale, provisioning packages for 5 of our enterprise products. And, he had never seen the language before. Management likes that, and, I suspect, now that he has seen the benefits of PowerShell, he too may turn to it over other languages more quickly. I would be scared to think of what it would have taken to do this same project in VBScript. Maybe 6,000 lines.