First week
May 6th, 2007
I wrapped up my first week as a full-on Xerpi Geek and cannot be happier. I feel like I've gotten more done in one week than I did in the previous month or so! Along with some cool improvements and enhancements to the beta codebase, I completed a balanced (balance between complexity, generality, and practicality) domain model and just about defined all of the business services. By mid-next week, I should be pretty deep into implementing the tests for these services and therefore start on the implementation! In the overall MVC application architecture, my plan is to go top-down from the controller interface (whose parameters directly drive the object model) and therefore build the controllers/models first leveraging Rails scaffolding for the base view implementations. Of course, we will pick up with adorning the views as appropriate after the "business tier" is mostly complete, for I know there will need to be some refactoring in order to support some of the user/organization-based view customization we currently provide and desire to improve.
I just can't say it enough -- this work is so refreshing for me. You see, I've spent way too much time and effort trying to convince others (typically management) that this Engineering / common-sense approach to Application Architecture and overall Software Systems is not just useful (or maybe in their opinion wasteful), but truly the professional way to build software. It was especially frustrating to be hired to come in and re-architect something when 1) the business did not want to spend time (re)defining the problem domain (so I could truly validate a design) and then 2) the business really wanted a re-shuffling of an existing architecturally unsound product. Combine the two and it spells huge frustration for folks with background and experience like myself.
Xerpi management just gets it. They/we understand that your first implementation is not necessarily your best (this is probably like number 3). You try to get some objective measurements and are flooded with subjective comments on what you have and, if necessary, discard what needs to be (even if it is the guts) and rebuild. And throughout that process, you get to redefine your strategy, goals, and objectives to ensure that the next iteration of software is aligned with the latest thinking. Ultimately, our software will be used more and more as the core becomes more stable (and abstract you Robert Martin/OO followers) so that when we reach that point where our system needs to be maintained by many and reliably scale, our system will already have all those ilities. My goal is to ensure that we won't have to call in the "Architect" to save our business from a flawed foundation. And, you know what, if we do, then we shall let her/him do what is necessary to sustain an optimal system.
I just can't say it enough -- this work is so refreshing for me. You see, I've spent way too much time and effort trying to convince others (typically management) that this Engineering / common-sense approach to Application Architecture and overall Software Systems is not just useful (or maybe in their opinion wasteful), but truly the professional way to build software. It was especially frustrating to be hired to come in and re-architect something when 1) the business did not want to spend time (re)defining the problem domain (so I could truly validate a design) and then 2) the business really wanted a re-shuffling of an existing architecturally unsound product. Combine the two and it spells huge frustration for folks with background and experience like myself.
Xerpi management just gets it. They/we understand that your first implementation is not necessarily your best (this is probably like number 3). You try to get some objective measurements and are flooded with subjective comments on what you have and, if necessary, discard what needs to be (even if it is the guts) and rebuild. And throughout that process, you get to redefine your strategy, goals, and objectives to ensure that the next iteration of software is aligned with the latest thinking. Ultimately, our software will be used more and more as the core becomes more stable (and abstract you Robert Martin/OO followers) so that when we reach that point where our system needs to be maintained by many and reliably scale, our system will already have all those ilities. My goal is to ensure that we won't have to call in the "Architect" to save our business from a flawed foundation. And, you know what, if we do, then we shall let her/him do what is necessary to sustain an optimal system.
Sorry, comments are closed for this article.