I feel that it’s important to have a comprehensive approach to software
development. It’s not enough to be good at coding, or testing, or writing
documentation. It’s far better to excel at managing every step of the
development process in order to ensure the quality and consistency of the
end-to-end work as well as of the final product. I aim to do just that in my
work. Here I briefly outline my methodology for achieving that aim.
First, good software development starts with good planning and research. I
strive to attain a thorough understanding of what I’m developing by listening to
the people to whom it matters most: the users. By gaining insight into how
people in the target market think about the problem space, and by strategizing
about how technology can address that space, a picture of the product takes
shape. This research coalesces into a set of pragmatic requirements and goals
that balance the demands of a realistic development schedule with the needs and
desires of the target market.
Once the requirements have been identified, it’s time for prototyping. Task flow
diagrams of user interactions model the entire system. Evaluations from the
target market refine these schematics, shaping the look and feel of the final
product. I cannot emphasize enough the importance of seeking market feedback to
build solid and meaningful metaphors into the design. These concepts drive the
user experience and make or break the success of the final product. The outcome
of this feedback loop will be a UI, terminology, and object design grounded on
intuitive concepts, scalable technologies, and a reliable architecture.
Next, a talented development team must be assembled and backed by a dependable,
project management-oriented implementation infrastructure. Team-building is
crucial for the success of any product, and in software development, a diverse
set of engineers and specialists with complementary talents must come together
and work as an efficient whole. As a result, I consider it extremely important
to create a working culture of which team members want to be a part. Such an
environment doesn’t foster a sense of entitlement, but rather of conviviality
and excitement. If team members believe in what they’re doing, and they enjoy
doing it, then they’re likely to do it well.
And what they’ll do is actually create the software. Each element of the product
design must be broken down into its basic parts, fit into a generalizable
design, and built back up into meaningful objects. I further require detailed
documentation of every interface and implementation, as well as thorough unit
testing. In fact, the tests are often written before the interfaces are written,
ensuring that they will work as expected throughout the remainder of the
development process. All aspects of the application must be implemented
according to a scalable, maintainable methodology that emphasizes consistency,
quality, and efficiency.
The emphasis on quality naturally continues into the quality assurance phase of
the development process. The feature set is locked so that development engineers
can work closely with QA engineers to test edge conditions, identify bugs, fix
them, and ensure that they remain fixed. I prefer to have QA engineers punish
nightly builds with suites of tests while development engineers fix the problems
identified by previous days’ tests. QA is considered complete when the product
passes all the tests we can dream up.
And finally, once all of the QA issues have been addressed, the final product is
delivered. Naturally, the process doesn’t stop there, but starts over – in
fact, it likely has already started over. New features must be schematically
tested with likely users, and new interfaces designed to implement them. The
idea is to end up with a solid product that can grow with the needs of the
target market.
Looking for the comments? Try the old layout.