"RUPitUP!"

  
     
 

'basically' a completely blurred Vision!

  
     
  RUPitUP! is a blurred vision that has started with a fixed set of "not to do's" of Software Development. The past 3+ years of software design and development have been awesome and have been a tremendously rewarding experience! Mistakes have been made and thanks to god, a lot has been learnt. As a developer however it has been a heart breaking experience to see a software project and the construction of a building starting in the same month - a year later the building is standing tall and straight - but the software? Well, that's something any developer will be able to answer... if he's not too busy in fixing (hiding?) bugs! Turns out, transition of most projects is a nightmare for all parties involved! Any guesses why?

Thanks to god again, i've had a chance to witness projects that fail, projects that barely scrap through and projects that are successful. After the lessons learnt session of my last project (which thanks to god met the acceptance levels) i kept thinking about a few things:

  • Could we have done any better at planning?
  • Could we have done any better at committing dates?
  • Did we compromise quality of code to meet deadlines?
  • Did we implement RUP (in it's true sprit) to at least try and ensure that the software developed stands with confidence like the building standing tall and straight?
  • Was documentation too much and was it done just for the sake of doing it?
  • Was there too much pressure on developers to code @ a rate they are not comfortable coding at?
  • Did they have a fair voice in raising problems that might occur or quality depletion that might take place if they code @ that rate.
  • And Most importantly, Did all participants enjoy working on the project and will they like to support / enhance the project in future?
 
 

That's how software is developed!

  
     
  The argument seems exiting and could go on forever but RUPitUP starts on the basic concept that every participant likes the planned approach to software / project  development. A typical example to give here is excel sheets that are often exchanged between development and QA teams - at some point of time we as engineers of a domain that has evolved rapidly start believing that this is how software is developed! However, exchange of bug reports in excel sheets is not because participants don't like filing bugs on the bug tracking system - it's because their bug tracking system doesn't allow them to file bugs which are sure to get fixed without exposing them to the client.

"Your window of 'y' screen doesn't close when you click the close button."  - "Oops i missed implementing the close functionality in the code. thanks!" - Well, the QA team and developers want to avoid these conversations in the bug tracking system which the client has access to - mainly because, well, it's embarrassing! As long as the bug is resolved they are ok with that! so, they end up exchanging excel sheets and breaking up the process completely!

  

 
     
 

So How Does RUPitUP come in?

  
     
  There needs to be a  'practical' approach to RUP and other processes. It should support process guidelines. in fact, these should be built into the system. Of course, the idea is not to re-invent Rational Rose or Microsoft Project (or the wheel:) ). The idea however, is to bridge gaps and bring tools under one roof! A Document repository that has an option of creating RUP sections by default and sample documentation, A bug tracking system that give internal interface where developers / QA team members can exchange and track bugs without having to involve the client in insignificant details, A Request Tracking System where a developer can advice the PM that the request being asked for by the client will take 'y' man days over and above his work - anything under that will effect his quality of code! To cut a long story short - this is an attempt to make software development fun for everyone involved!  
     
 

How much of RUPitUP is already complete?

  
     
  The project is pretty much in it's pre-inception stage where we're trying to freeze on technologies we plan to use. The detail design document (nothing too elaborate / expensive) will be written by the end of January. Technologies will be identified by then. POCs of each technologies identified will be developed and will be hosted in the CVS by the end of January. Substantial Reading / Training material will be developed - so that new developers can read, learn and hop in anytime they want.