Today we are solving business problems by developing software
applications based on customer requirements. But how much time in a
project goes to the way of actually solving business problems? Are we
still fiddling with the unending setup, environmental, infrastructure,
management etc issues that hold us writing usefull code and
solving actual customer problems?
Everybody knows that time is money, and yet I have
seen examples around that some basic things in the name of automation
hasn’t been done. There are easy ways to save time and money by
implementing some of the things before thand. Here is my list:
1- Source Code Control
I don’t think that there is software development company out there who
is not using a for of source control system. Be it Subversion, Team
Foundation Server, GIT or a project on Sourceforge.net everyone uses
it. Even the toy projects that we develop at home are kept on our own
source control servers.
2- Unit Testing and
coverage
Unit testing is required what ever the language you are using, but unit
test alone is not enough; the coverage should also be good. Karl Seguin
on www.codebetter.com
explained it well on Chapter 5 of his free book
“Foundations
of Programming“:
Unit Tests aren’t only about mitigating
high-risk changes. In my programming life, I’ve been responsible for
major bugs caused from seemingly low-risk changes as well. The point is
that I can make a fundamental or minor change to our system, right
click the solution, select “Run Tests” and within 2 minutes know where
we stand.
3- Continues Integration
and monitoring
If you do not compile at least every night and run unit tests to see
where you are; you are in deep s**t. To perfect world would be to
compile at every check-in and pin point the scapegoat but it may not be
applicable if you are short of computing resources.
4- Documentation
At least a database design doco and a requirements specification should
be a must have for a poject. The API documentation can be generated out
of the code if it is properly commented. An automatised database design
process or a project wiki should give enough information for the
exisiting and new starter developers. Designing the system with a UML
tool and producing the requirements documentation out of these would be
preferable.
5- Bug reporting and
change requests management procedures
Once released a product out to the wild, the issues and bugs will rain
like cats and dogs. Having a good bug reporting system may save you
some dollars. Managing them should also be automatised with
notification systems. Change requests might be prioritised
automatically into releases.
6- Bug fix and
source control integration
Some changes to the source code may need to be attached to a bug or
issue so that PM can what bug is resolved with what piece of code.
7- Logging software errors
Having a system ready to use to log the errors in the software may save
you some time. As this is a system that needs to be built, it can be
inherited from a previous project. If you are building this for the
first time, make sure that its reusability is high and the API is well
documented.
8- Implementing database
and its changes fast and automated
One area that code generators and latest ORM wave is trying to solve
for you. Are you utilising any of these to manage your databases and
their change requests? Well, you should. Also having your database
design on a tool like Erwin or using the latest Visual Studio DBDude
mightt help you to manage the database easily.
9- Test, UAT, release
procedures
Internal regression tests, user acceptance tests and release procedures
are also another area. During the development of your project, you
might have a wiki for developers to spell out the test scenarios and
later use these for regression tests, or give them to UAT people to
execute. Releases should also be inline with these test scenarios and
with every release (major or minor) a new version of test scenarios
should be distributed to the parties. If you automate this into your
compile-unit test-package-release cycle, you will be the king.
10- Communication
procedures
Communication is the most important thing in a project team but too
much of it will bore you. A translater between the customer and
developers and also another translater between the developers and
project manager might be necessary. Short meetings and outcomes of
items above may be used for reporting and scheduling tasks. I
am not telling to isolate developers totaly, they are free to talk with
any stakeholder of the project. Those interfaces are realy time
savers when it comes to sign-off’ of requirements
documentation or change requests approval.
So what do you think? What else can be automatised to speed up the
development process?
