Five Best Practices for Programmers

Is it hard for you to focus while you’re trying to write code? Do you and your team struggle with deciphering what went wrong when you’re debugging? Have you ever been embarrassed by a program that hangs during a demo?

Dice News C++/C# and Java Talent Community Guide David Bolton takes you through five best practices for programmers that will not only make your life easier – but could also help you do your job better.

 

Dice News Hangouts

Comments

  1. BY Shantal says:

    I am personally not big fan of Scrum. It is a system that encourages a programmer to rush development which results in the need for ever increasing numbers of bug fixes. It also creates an environment that is not product and customer oriented. A higher quality product usually results when the environment is team centered and more creative as opposed to being primarily competitive. As a contractor I have witnessed most projects being scrapped under the Scrum process more than any other development process. I was personally once fired because of a demo that delayed during a Scrum meeting and this was due to a bug that was actually initiated by a developer with more seniority. Because I ran the demo during the Scrum session, it was decided that I should be let go. In my opinion, developers should be allowed to test their own code and be given greater autonomy in the testing environment which prevents another developer from being blamed for an external programming error. Scrum also decreases the level of effective communication in environments where team members are often of varying skill sets and based in different locales where they may be less able to participate in real time.

    • BY Deepthoughtm says:

      I’m not sure what part of the Scrum manefesto or any Scrum book that says a developer should rush development. Scrum has the opposite effect. Since you know ahead of time to a certain degree of certainty what work can be completed within an iteration, usually a dev team experienced with estimating their time will use conservative estimates as to how long it takes to finish. If a team underestimates a task, the team adjusts. In some cases a dev may have to work a little bit harder to meet a deadline. Can you name a methodology where programmers don’t attempt to compensate for slippage?
      “As a contractor I have witnessed most projects being scrapped under the Scrum process more than any other development process…”

      I believe you. I have seen Scrum projects scrapped as well. Here are the reasons
      1) Inexperienced Scrum Teams and practicioners.
      2) Stubborn,old school, stuck in the silo of waterfall engineers and managers that sabatoge new scrum efforts. Scrum exposes fraudulent, weak developers and testers. It is based on constant sharing and openness.
      3)Scrum malpractice – This is actually an extension of 1). Some practitioners blend methodologies because of the order to fulfil some departmental mandate to become “Agile” and still keep their old waterfall habits of trying to plan an entire project up front or code a bunch of crap and pass a huge mess and blame testing etc… Blending Scrum works very well when the practitioner know what they are doing. The “Scrumbucket” practicioners break the rules without trying to understanding them first.

      Scrum is simple but not for simple-minded. Scrum is also not for every project but to say it is not product and customer oriented, I have to disagree.

  2. BY Jay says:

    Shantal, I agree with you 100%. I have seen three projects that are failed due to “Agile/Scrum” process and recently with my last two clients, I have been involved in helping them move from “Agile” to normal SDLC methodology…Not sure why companies are not getting the message and comprising their Product/Project Quality and spending double the amount while fixing defects after being rushed to production.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>