20 rules for delivering software products

5 11 2006

During my time as a software developer, I’ve observed that many of the problems affecting product development in the software world can be resolved if you follow the following rules. Product and project managers: please take note.

  • Make sure you know what you are building. Many project delays are because the “customer”- the manager, corporate head, (you?) doesn’t actually know what they want.

[Update] Recognize that what you need to build will change all the time. Make sure your process supports this and that you reconcile the change with the point above.

  • Make sure you only work on things that you need to ship with version 1.0.
  • Make sure you always keep the prototype running.
  • Show demos every few days to make sure no one is confused about what is going on.
  • Don’t make any project your time to show how clever, cute, or interesting you can be.
  • Small is good. Keep Teams/Egos/Methods/Files/Modules/Projects/build times small.
  • If someone is not clicking with the rest of the team:
    1. talk to them privately,
    2. reassign them,
    3. if this person is you, read #9, and consider if you want to build this project, or do something else. Follow your heart.
  • Do the riskiest part of the project first.
  • Make sure you’re in total control of your toolset and improve it systematically
  • Do not take the clients’ deadlines literally – first accept the project, then renegotiate the deadline.

[Update] I do not mean to imply that the clients’ constraints are not important. I’ve seen too many examples of team heroics to meet deadlines, when it would have been OK from the client’s perspective to slip by a reasonable amount of time. Keep the lines of communication open and balance the needs of both parties.

  • Design your software around interfaces so you can make massive changes cheaply.
  • Document the interfaces perfectly, but don’t document code (see next point).
  • Be fanatical about the readability of code.
  • Remember that the enemy of the better is the best.
  • Push all QC, packaging, and issue management through a single team.
  • Build regression testing into the build process.
  • When debugging a problem, never ask, “how come it works on my box?”
  • If some code is too complex to understand on a Monday morning before coffee, redesign it.
  • Never add new code while there are still major bugs in the existing code.
  • Don’t worry about it. If you are working hard, and follow 1-19, you are doing your part.
    About these ads

    Actions

    Information

    12 responses

    8 12 2006
    8 12 2006
    James Taylor

    nice list. I think #1 and #14 need some edits – check out http://www.edmblog.com/weblog/2006/12/using_business_.html for my thoughts.

    9 12 2006
    Rob Grady

    Great list to generate dialogs around existing processes and procedures.

    9 12 2006
    Rishikesh Tembe

    Thanks for your feedback! I’ve updated the post to reflect some of the great points that were raised.

    9 12 2006
    12 12 2006
    Paul Todd

    I would like to add Code Review. Review often and always team review junior members code before they go into the dev line

    16 12 2006
    Vahishta

    As someone who is on the other side of the fence – the client! I would like to say that keeping your communications open is the number one thing that would make me comfortable about working with someone. Great post!

    20 06 2008
    Lectura: Reglas para el buen desarrollo de un producto? - VB-MUNDO - Programacion Visual

    […] Lectura: Reglas para el buen desarrollo de un producto? Reglas para el buen desarrollo de un producto 1. Asegrate de saber qu ests desarrollando. Muchos de los retrasos en los proyectos se deben a que "el cliente", el/los analista/s, los programadores, etc. (inclyete en el pack correspondiente), no saben realmente cul es el objetivo final del proyecto. Reconoce, aade en una actualizacin del post, que lo que ests desarrollando ahora mismo, cambiar casi de forma irremediable en el futuro hasta completar el proyecto, as que asegrate de que tus procesos, clases, sistemas o subsistemas, admitirn estos cambios preparndolos para ello desde el origen. 2. Trabaja solo en los puntos necesarios para lanzar la versin 1.0  Sin olvidar lo mencionado en el punto anterior, claro… 3. Asegrate de mantener un prototipo siempre funcional  Si lo vas actualizando con las ltimos desarrollos, y lo mantienes accesible a los usuarios finales, podrs ir corrigiendo o debatiendo con ellos desde la interfaz a posibles malentendidos en las funcionalidades de la aplicacin, con lo que podrs, entonces, anticipar estos cambios en las partes que aun no has empezado o tienes entre manos… 4. No hagas del proyecto un escaparate para mostrar lo "guay" que eres  Aqu… no es que discrepe, pero… si tu proyecto puedes aprovecharlo como escaparate del buen desarrollo y buen hacer de tu empresa o grupo de trabajo, es posible utilizarlo como un trampoln para futuros proyectos… o a la inversa, si la picias o el cliente no queda contento… una puerta abierta menos… 5. Lo breve, si bueno, dos veces bueno… osea, mejor las cosas pequeas  No seas mal pensado… estamos hablando de los mtodos, ficheros, procesos, funciones…. 6. Si alguien no est en sintona con el resto del grupo…  Habla con l/ella en privado  Reasgnalo o cambia sus tareas o funciones  Y si eres tu mismo… recuerda lo del escaparate… 7. Disea los mdulos o clases construyendo interfaces, de forma que sea accesible facilmente por terceros mdulos, reutilizable y facil de implementar cambios masivos.  Documenta estas interfaces a la perfeccin, pero no los mdulos o clases que usa la interface, eso s, mantn una escrupulosidad absoluta en la facilidad de lectura y mantenimiento del cdigo de estos mdulos. 8. Cuando ests en el proceso de debug de un problema, nunca digas Pero si en mi equipo funciona !!!  Quin no lo ha dicho alguna vez? 9. Si hay algn fallo de funcionalidad o algn bug grabe en la parte ya desarrollada, no continues con partes de cdigo nueva hasta haber resuelto estos problemas 10. Si alguna parte del cdigo es complicada de seguir el Lunes a primera hora, antes del primer caf, redisalo. Despus de todos estos puntos, sera casi obligado hablar de algunos temas importantes, y debatir sobre ellos:  Tomas de especificaciones.  Reuniones de seguimiento con los clientes/usuarios y con el equipo de desarrollo.  Equipos multidisciplinares o equipos de especialistas  Prototipos, maquetas, beta releases… Y prometo ir ocupndome poco a poco de estas cositas… por supuesto, necesito de tu colaboracin, opiniones, crticas, experiencias… no te cortes… Y por lo ultimo que si no te sale o estas turncado en un codigo, lo mejor y recomendable es apagar la maquina y despejarte tu mente, cuando vuelvas a trabajar en tu proyecto ya veras que si te sale. tomedo del la web 20 rules for delivering software products Product Musings […]

    21 07 2008
    Great Post:20 rules for delivering software products | Rob Grady

    […] Great post and I love Rule #1 […]

    6 10 2008
    steawist

    Cool post.., dude

    18 05 2010
    John Decruz

    Yes.. the people need to follow when they delivering software products. Software Products are helpful for the business to get the higher efficiency of the business. Thanks for sharing most useful information which is rules for the software products with us.

    11 11 2013
    What does it take to deliver a software product? | Ask Programming & Technology

    […] Is there good literature out there which I can read? I was just reading this wonderful article, http://productmusings.wordpress.com/2006/11/05/20-rules-for-delivering-software-products/. And one point I really liked was “Make sure you only work on things that you need to ship […]

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s




    Follow

    Get every new post delivered to your Inbox.

    %d bloggers like this: