<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/platform.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d6651501\x26blogName\x3dNotes+on+tech\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLACK\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttps://ypjain-notesontech.blogspot.com/search\x26blogLocale\x3den_US\x26v\x3d2\x26homepageUrl\x3dhttp://ypjain-notesontech.blogspot.com/\x26vt\x3d-1979808972264517134', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>

Notes on tech

Notes on technology, business, enterpreneurship, economy, markets along with interesting general tidbits.

14 rules of software development

10/03/2004 11:23:00 PM, posted by anand

While reading Rajesh Jain's blog - Emergic, I came across a post in which he mentions Barry's (Barry Briggs) 14 rules of software development. I am briefly stating some of them here:

1. Great software is built by small teams. If you're building a great BIG software product use lots of small teams.

2. Great software projects always, always have one person who gets the big picture. This person is called the architect and s/he codes.

3. Never check-in code that causes the build to break. Always perform basic sanity test first before checking in code.

4. Source files should always contain comprehensible, grammatically correct comments. The comments should reflect the fact that the coder knew what s/he was doing when writing the code.

5. Test/QA is not there to find bugs. You are there to find and fix your bugs. Test/QA is responsible for telling manager(s) and customer(s) if your code is any good, and if it's ready to ship.

6. XML does not solve all your problems. Neither does model-driven design, or UML. You still have to write good code.

7. Great software architecture requires thought in advance.

8. Every coder must spend at least one day per year listening to a customer complaining bitterly about his/her product.

9. Coders with Big Egos usually have Big Problems with their code.
« Home

» Post a Comment