Tag: software development life cycle

The lazy but over-confident Software Developer; Or why we need testing

I myself am a Software Developer… but this is true for some:

why_sqa
This is why we need SQA

– Manish

Rules for Developing Safety Critical Code

Came across a nice paper by NASA/JPL scientist Gerard Holzmann on coding guidelines.

Fun Notes:

  • Interestingly, I recently wrote a couple of posts on the very same topics discussed in the paper – on function calls and macros – in my earlier posts. Amazing how events happen in this universe.
    🙂
  • I’ve worked on a project in which I blatantly broke the first rule – by using setjmp/longjmp to gracefully handle asserts and error-conditions.

Here’s the link to the paper The power of Ten — Rules for Developing Safety Critical Code.

Breaking and Stripping Down a Product / Project

Breaking a Product / Project

We all know that breaking down a problem into pieces is a good idea. It makes the problem approachable and manageable.

That’s what we do in real life and during software development. We break it into smaller problems and tackle each of them individually.

This process has one more added advantage… the solution to one of the smaller problems can be re-used when you break-down another big problem. That’s the idea behind functions and classes in C++ (and many other programming languages).

Other than breaking down there’s one more concept – the concept of Stripping Down.

Stripping a Product / Project

Stripping involves getting rid of all the ‘clothing’ so that the product is left to it’s bare minimum – bring it down to the basic functionality. For eg., remove all the GUI components, remove all the fancy features, study and remove everything that doesn’t affect the basic functionality.

A stripped-down version can be implemented relatively quickly than a non-stripped version. And a working stripped model gives a lot of confidence that the whole product would eventually work well – a comforting situation for the developers.

Once you have the basic model working, start putting the layers of clothing. This is a very systematic process and leaves very little room for surprises – if there’s any surprise, you would encounter it very early in the project life cycle.

Another advantage of this process – you can do a quick feasibility check: whether you are going to meet the requirements. Maybe some minimum speed requirements, or some memory constraints.
And if required, the team can take measures accordingly, before it has moved too far ahead that any changes would cost a lot.