Ahsan Askari asked the following in a comment to one of yesterday’s posts:
Just like to know whether you use external libraries specially ‘BOOST’ in your commercial projects and related pros-n-cons ?
*Also i like to know your initial strategy of Software development. I mean you’ve written a lot about your coding and tsting techniques but i like to know how you start the project, whether you believe in UML and how you carry out analysis.
Here’s the answer…
I don’t currently have any code that requires Boost. Every now and then I take a look at the latest stuff over at www.boost.org but, so far, I’ve found no compelling reason to add a dependency to these libraries. What’s more I still have a lot of clients that require me to use Visual Studio 6 and the current version of Boost doesn’t build with that. Things that look interesting and that I could be using but don’t due to the above include
My “initial strategy” for each project is pretty simple. I like to get to working code that demonstrates the core idea of a project as quickly as possible. I aim to get a single thread of functionality from “front” to “back” before fleshing out any one point of the development. This effectively proves that the project is viable at the lowest level. This can take a little while, depending on the project, but that’s OK; I consider it a prototyping phase. For example, at present I’m working on a tool to help me determine if an executable could deadlock. The first phase was to run a reasonably complex app inside the harness and track lock acquisition and release. It took me about 3 days to get that proof of concept and whilst working towards it I dropped a few of my normal rules to boost my speed towards the “is this a viable project? Yes or no?” decision point.
It’s actually quite interesting to think about the rules that I dropped and those that I didn’t:
Most of the code was still developed in a test driven style but I didn’t immediately hoist the code under test into a library to link with a mini executable shell (this makes code easier to test). Instead I simply pulled in the files under test from the exe project on a file by file basis. I also didn’t create a separate mock object library, that all ended up in the test library too. This saved me setting up a couple of projects and probably isn’t worth the saving on projects that get a “yes” and go forward as I then have to do the work anyway and the work isn’t that difficult since I edit dsw files and use search and replace to create most of my projects so it doesn’t take me long.
I used a bit of Frankenstein programming; grabbing some code that looked like it would do what I needed and just slapping it in there to solve one of the problems knowing that should the project go further I’d need to rip out the borrowed code and work out write some testable and reliable code to my coding standards that provided similar functionality. The aim during those 3 days was to get from A to B so that I knew if it was worth pushing on to C and D.
Most of my other development practices stayed the say; no bugs, everything in CVS all the time, testing, nice clean code, etc.
Assuming the project should continue the next phase is one where I “regroup”. I take the code that got me from A to B and package it up into our standard form; so the “nasty web code” gets pulled out and rewritten with tests and packaged in its own library. The tests around the other code get examined and enhanced, etc. The aim of this stage is to leave me with usable code even if the project never goes further or if it tries to go further and fails at a later stage. This part of the project is really, really, important to me. It means that my library of “useful” code grows quickly and that if I later find that I need code that was used in a previous project I know that I will be able to reuse it pretty quickly because I know that it will have been designed in my house style and that it will play well with my other code.
From there it’s a case of picking the next most risky aspect of the project and doing the same again until eventually all you’re left with are nice to have feature requests ;) For example, the deadlock tool’s next step was for me to obtain call stacks of the lock usage so that when it reports on issues it can detail exactly where the problems are.
I use aspects of UML when I think it adds value. I expect that if you’re working with a large team and all of the team understand the “same UML” as you do then there’s more value in it than in my environment… You only need to look at the UML web site to see how big it’s grown; most of what’s there doesn’t add value for me in the situations that I tend to find myself in. I’m sure it makes the tool vendors rich though ;)
That said, I occasionally find it useful to draw class or object diagrams; either by hand, on paper, or in Visio. The thing about drawing these diagrams is that I usually only do it when I find that I can’t keep the design straight in my head. Dumping the design to paper, manually, means that I spend time thinking about the design and drawing it out. I have a rule of thumb, if I can’t draw a “pretty” (see “correct”) class diagram then the design needs cleaning up.
Then there are my scribbles, I don’t class these as real diagrams as I don’t use any particular notation. They’re the box and line diagrams that I scribble onto the paper that sits between me and my keyboard. I draw them almost all the time and I screw them up when the thought has turned to code.
I ask lots of questions, either of the client, or myself. I don’t settle for “because that’s the way it’s done”. I ask “Why?” and awful lot and I try not to let people fob me off just because they don’t know or don’t want to think about it. It means that sometimes I can be a bit annoying as sometimes people don’t want to have to admit that the real reason is that they don’t know; but heh, that’s my job.
All of the above is mostly how I do things on projects where I have complete control. Things can get more formal as and when they need to or if clients request/require a more formal approach. I often have the luxury of working in a team of 1, or in a small group. Documentation usually happens at the end and is provided to the level of detail that the client requires and is prepared to pay for. All of this stuff changes when I find “better” ways of doing things.