During my many years as a product developer, I always focused primarily on 3 things. Usability, or the aspects of a product that make users find it easy to work with; a clear and well-designed implementation of the code itself, making the product easy to maintain and enhance; and use of current technologies. As a software architect who exclusively worked with a development manager, I was responsible for coming up with the design of the software, listening to his input on what the user needed to do, and making the implementation great. However I left it to him to communicate the status of the project’s deliverables to upper management, though I would help present technical information to them with him.
Since crossing over into the world of consulting, something I’m constantly striving for balance in is this desire I have for creating excellence in the product with a predictable schedule for delivery.
In product companies, it is important not to blow your schedule out of the water, but if you are delivering a platform upon which many other products will be built, or a flagship product line in a new market, hitting that strategic target in the marketplace and in the usability of your application gives you some leeway (though that can easily be taken away, and is non-existent at companies that do not understand software development at all).
However in consulting, it is much more important, depending on the project, to provide a predictable date for delivery of your promised features. This is especially true on projects, such as the one I’m working on now, where the work we are doing for them coincides with business moves made by their organization and must be in place by a certain hard date.
This shift in perspective has caused me to re-evaluate how I design software. I find myself asking more often whether how good something looks is worth the time I spend on it. I also question whether the way the code is written really needs to be as maintainable and clearly documented as I’d expect before. This mindset change has resulted in a few interesting realizations.
Catapult Systems (where I work) is an amazing company. The vision and structure of the company is such that you really are almost like your own boss on each project if you come in with leadership qualities and significant experience such as I have. It has been a bit difficult going from top technical guy at my past 3 jobs to being a colleague of many with similar skills, but I am taking every opportunity to learn possible and hoping I will prove my ability to innovate and really create solutions for clients that are above and beyond a typical consulting implementation with my first opportunity for involvement with design through implementation on a new code base.
Catapult is growing so fast that we are using proven techniques to manage projects and design our code, but not forcing one methodology on everyone. Though there are folks here that are trying to come up with common standards for some of these, there is an understanding that each team is different and each client has different needs from an engagement and documentation standpoint. I hope while I’m here to find more ways to get folks to build time into the schedule for, and convey the importance to clients of, more focus on usability and quality. This is not at all to say that the existing projects being done here don’t consider these aspects (and on the Sharepoint projects it’s probably more prevelant). However I think we can do even better.