I have been in a lot of meetings over the past few years where inefficiencies in a few practices and policies were being discussed. In terms of software development, there's a lot of things that can be done to improve how the code is written, deployed, and tested. The meetings began talking about these possible options; however, after about a 10 minute discussion in the first meeting, everyone seemed intent on designing the tools specific to their domain and not the groundwork that is common across all domains. Now, nothing is wrong for discussing features to standardize an approach and not reinvent the wheel every time; however, I have learned that the features are domain specific (albeit some may be more common than others) and it's the recreation of the fundamental code that saps a developer's energy, focus, and motivation usually.
Years have went by and still the same people talk about the features without giving any thought into the remedial code that is common and takes the longest usually. Between debating the aspects of the features and evaluating tools, such turned into analysis paralysis very quickly with very few realizing it. Soon, the feature advocates turned more into idea zealots; preaching their views while not provided any acknowledgement to other opinions.
Because of all of this talk and no action, I began to run a few tests with some of my colleagues. There were 3 projects that shared the same core project foundation in it's design but each developer was going to create their own. For the sake of this story, we'll say that this was going to be a "professional" Hello, World console application that had to handle industry standard command line arguments (i.e. -? and a few others). Each person took about 5-6hrs writing the basis of their console application; setting the proper output color schemes and the console output for the help information and other fundamental requirements. Finally it took them about 1hr to do the actual project specific logic. Now, in this example, one could say that Developer-A creates it and then passes it along to the others in a copy/paste sort of way; however, the test needed to be done not only for time purposes but for implementation purposes since all 3 application bases were not consistent.
From these examples, we refined the foundations and eventually abstracted it into a Visual Studio project template. The next time they they had an opportunity to use the template, it saved them that much time yet again. This template was only the fundamentals and didn't have any actual features (no consistent way to do things like emailing or FTP services or error handling). Later versions have added these features into it (or provided a model to make it easy to do a custom implementation) but the original versions were just the fundamentals.
In the end of this experience, the idea zealots were still preaching their features without recommending any solution to their implementation and we became more efficient by automating the fundamentals. If you're looking to improve efficiency, try to find remedial, repetitive areas in your process and see about automating them. Start with the fundamentals and then add features to it. There'll be changes; however, if you Develop > Refactor > and then Abstract what works, you'll be in a much better place than if you stayed in a meeting room and debated about what features should be in the initial version of the script or template. My Rule of Thumb from experience: Version 0 of any automation script or template should only have the minimum amount of features possible and focus on the fundamentals.
No comments:
Post a Comment