There are many aspects to a software development project. Many roles need to be filled and in many cases many people will be required to ensure that each role is adequately covered. Moreover, the more people a project involves, the more management overhead is required in order to coordinate such an effort. Additionally, it takes time to bring all these people in and, upon project commence, hope that there are no interpersonal conflicts or other issues that may affect project progress. Sounds expensive and it is. However, there is a slightly more cost effective option…
Engage My Services
The reason you may want to do this is you get an individual who not only has experience all the above roles but has had this experience whilst working with some of the biggest names out there…
- The Gap
- Organic (24 Hour Fitness web site redesign)
- Applied Biosystems
- P G & E
- A. C. Nielsen
This is where things can really start going wrong. The number one culprit is not defining the requirement sufficiently to truly understand the scope of work required to fulfill it. Knowing when a requirement is too vague takes years of being involved in the requirements gathering phase to instinctively know when things need further exploration. Having been involved in requirement gathering of one form or another for twenty six years, I am very much in tune as to when something needs further examination including an uncanny ability to sniff out esoteric edge cases.
Aside from years of being involved with this phase, on the UI front, I’ve also developed techniques that go beyond storyboarding to provide the user with a more dynamic experience allowing them better understand the nature of the various interactions of a given UI. This leads to a UI artifact (screen, portal, etc.) that in many cases ultimately becomes part of the final deliverable. What this basically means is that development is occurring during the requirements phase incorporating direct input from the end user.
It is during this phase that one is presented with the opportunity to completely lock oneself into a inflexible design which will no doubt require a complete application rewrite when version 2.0 is needed. Alternatively, you can hire a designer / architect who will ensure that this kind of lock in does not happen and some if not all of the previously developed components can be reused with minimal modification. Also, well designed applications are much easier to maintain leading to significant cost savings over the lifetime of that application. Besides, when developing the UI for the various platforms out there, would it not be nice to be able to reuse the same components for desktop and mobile? Good design will allow this.
Having been involved in architecture for the last nineteen years, I know design. As importantly, I know when to not to over design. Examples of this include designing for performance when there is no evidence that the area in question will have performance issues. Another is proposing an SOA solution when there is no demonstrated need for services. Given that in many cases, I have also built applications based on my own designs, I know to keep a design relevant and when and in what areas a logical design will need denormalizing before becoming a physical design. Please see my ‘ramblings’ for more of my thoughts regarding design.
I’ve been involved in the iterative design / development process for 21 years in both RUP and Agile / Scrum environments. Given my roles as both an architect and developer in these environments, I am quite familiar with the issues that arise and have arrived at designs that insulate against such eventualities. Being involved and having others involved in the building of my own designs means none of this has been done in a vacuum.
All the Rest
In addition to the above, there are other tasks that will contribute to the success of a project. These include establishing a continuous integration environment. A continuous integration environment helps detect coding problems before they have a chance to propagate too far. However, unless you’re doing test driven development, the usefulness of this will be limited.
Having been involved with test driven development for 14 years, I will be happy to outline the procedures and processes that need to be followed to ensure what is referred to as ‘good code coverage’, essential in automated testing.
Another important consideration for team based application development are the team members themselves and how proficient they are both with the language of implementation and how to incorporate good design into the code written. Code reviews can mitigate this and, like continuous integration, catch issues before, again, they have a chance to propagate.
Naturally, having designed and written object oriented code for the last 20 years, one starts to see certain patterns of developer malfeasance. Also, one comes to realize the code reviews are essential when working with a team of developers with wide ranging experience levels.
For further details including an initial consultation, you may contact me on my cell at 408.807.9166 or via e-mail at email@example.com.