Consejos y Procedimientos Utiles                            Para el Diseñador de Sistemas Pequeñoss

• Hay una especie de "regla de tres" que el programador de sistemas pequeños siempre debe tener en mente: hay que evitar los tratos con el dueño de la empresa.
  
  El dueño, que es el que finalmente paga los honorarios pretenderá sacar lo más que pueda a su dinero, regateará las tarifas hasta el último centavo y esperará como cosa natural obtener servicios de mantención gratis por tiempo indefinido.
  
  Especialmente  peligrosos son los empresarios que se hacen amigos del programador y, los peores de todos, los que tienen el hobby de la computación y creen ingenuamente que el programador lo comparte. Esa es la regla número uno: hay que tratar siempre con el gerente, no con el dueño

• Al diseñar un sistema pequeño se parte siempre por la salida, lo primero es hacerse una idea clara de lo que el cliente quiere tener en sus manos como producto del sistema. 
  
  El problema es que muy pocas veces el propio cliente tiene esa idea y solo espera beneficios vagos como "controlar", "ordenar" o cosas por el estilo. Aquí es fundamental ayudarlo a definir productos específicos que entregará el sistema, .Los productos finales deberán estar especificados en todos sus detalles antes de escribir la primera línea de código

• El diseño de sistemas es uno de los pocos campos donde no se aplica eso de "el cliente tiene siempre la razón", las ideas del cliente solo deben ser una guía general pero el diseño es siempre de responsabilidad del programador.
  
  Tal como un arquitecto se puede negar a diseñar cierta estructura si piensa que se va a caer, un diseñador se debe negar a hacer un sistema si le parece inseguro, ineficiente, incompatible on la capacidad del hardware o, lo más importante, más allá de sus conocimientos o capacidades. Un buen diseñador solo acepta sistemas cuando sabe exactamente que pueden hacerse y como hacerlos
  
  

• Una vez en posesión de las especificaciones del diseño, este debe completarse tal como fue diseñado. Los cambios sobre la marcha, especialmente cuando afectan a criterios fundamentales del diseño son una garantía de fracaso. El diseño jamás debe desviarse de su objetivo general ni de los específicos. En caso que se cambie de idea sobre los objetivos hay que volver a comenzar todo a partir de cero.

• En sistemas pequeños el orden de prioridades es mas o menos así:

  Funcionalidad: que el sistema funcione como se espera sin fallas

  Simplicidad de uso: que cualquiera lo pueda operar y mantener con mínimo entrenamiento

  Tolerancia a errores humanos: que sea tolerante a  equivocaciones, que los errores se puedan revertir y corregir con facilidad

  Ergonomia: Presentacion visual cómoda, bien organizada y que requiera de un mínimo absoluto de acciones de parte del operador.

  Simplicidad de diseño: minimizando los menús y datos de entrada requeridos, la calidad de un sistema pequeño es inversamente proporcional a la cantidad de capos de ingreso de datos y menús.

  Mantención cero: las tareas de mantención deben ser automatizadas al máximo y simplificadas de modo que los propios operadores puedan mantener los sistemas.

  Eficiencia: en último lugar, la eficiencia es muchas veces irrelevante en sistemas pequeños y normalmente debe ser sacrificada cuando está en conflicto con alguno de los criterios anteriores.

• Documentación: los sistemas pequeños pueden ser autodocumentados, pero al trabajar an Visual Basic que es extremadamente permisivo con el programador (deliciosamente permisivo, diría yo) es muy común la escritura de codigo redundante, pobremente definido o inconsistenete. El problema de la inconsistencia del código no está resuelto en ningún lenguaje de programación conocido por lo que se debe hablar de "niveles aceptables" cuando un sistema comienza a ponerse complejo.
  
  Con relación a esto existen excelentes programas robot que analizan el código escrito, detectan problemas de optimización, inconsistencia y estilo y hacen análisis métrico de los programas. Su uso es sumamente recomendable y una vez que nos aficionamos a ellos es dificil dejarlos.