1. Seguridad excesiva. Sí, el no poder instalar los programas que necesitamos o tener capado Internet (o Spotify), no es la mejor manera de hacer la experiencia de desarrollo más dulce. 2. Obligación de usar herramientas horribles. Como tener que programar en Dreamweaver como IDE, por ejemplo. 3. El equipo de mantenimiento. Desde luego que los nuevos desarrollos animan a darlo todo que tener que encargarse de mantenimientos de proyectos anteriores. [...]
Comentarios
Con perdón para el autor original, pero la mayoría de puntos son lloreras por cosas que ha de soportar casi todo empleado por cuenta ajena. Llamarles "tortura" es de aguantar más bien poquito.
Edito: la versión en inglés es mucho más específica y comprensible. No es lo mismo quejarse de la excesiva seguridad porque te ralentiza el trabajo que porque no te deja escuchar Spotify.
#3 Y es así como se frena la productividad en España.
#4 Compara qué considera tortura el de la versión española y qué considera tortura el de la versión inglesa y verás realmente por qué no somos productivos (empezando por que no tenemos sangre ni para traducir algo en condiciones).
#7 En España hay grandes profesionales en todos los campos. Son las empresas españolas son las culpables de que la producción sea pésima.
#3 No sé si en otros trabajos es comparable (supongo que en muchos sí), pero como desarrollador te comento cuál es el "problema": Existe el pensamiento generalizado entre los desarrolladores de que son (o somos) más listos que nuestros jefes y tenemos bastante más claro cómo deben hacerse las cosas. En muchas ocasiones es cierto, entre otras cosas porque dichos jefes nunca han sido (o hace mucho tiempo que fueron) desarrolladores.
Dicho esto, varias de las cosas que se dicen están bien razonadas (en el artículo original) y estoy de acuerdo al 100% con ellas.
#6 Preferiríamos "maestros" (en el sentido grande de la palabra) y nos dan "jefes". Vale. Nada que no se pueda sobrellevar gestionándolos nosotros a ellos.
#6 Desarrollar es una cosa, y gestionar proyectos otra. El problema muchas veces es la ceguera de los ingenieros a su parcela en particular, y su falta de visión de conjunto, aunada con su soberbia. Los que dirigimos a desarrolladores sabemos muchas veces que no tenemos los conocimientos para programas, pero es que en un equipo hay muchas más piezas que simplemente los ingenieros. Y no, no siempre son los que tienen la razón, ni los más importantes.
Y todavía no he encontrado un sólo desarrollador que entienda esto a la primera de cambio.
#9 Trabajo en un entorno clavadito al que comentas, y no hay problema ninguno. Te explico:
- Para el mantenimiento da igual qué SO uses. Cualquier sysadmin es capaz de administrar cualquier SO (que no son tantos ni tan diferentes [quejicas!]). Y si no puede, es que es un inútil que no merece trabajar de sysadmin. Tan simple como eso.
- Lo de las licencias es una chorrada. Las licencias se venden por (copia de) producto, no por software sobre el que se ejecutan. Si tienes 10 licencias de un programa, te da igual que éste se ejecute sobre unix, windows, o un tapete de franela. Otro cantar son los servidores de licencias. Pero en estos casos el software no suele ser multiplataforma, así que sigue dando igual qué SO uses. En el peor de los casos sólo habría que montar un segundo (y/o tercer) servidor de licencias para el(los) otro(s) SO que se esté utilizando.
- Lo de las "pruebas conjuntas integrables" no sé qué pinta ahí. Aunque todos usen el mismo SO e IDE para programar, seguirá habiendo problemas a la hora de arrejuntar código de distintos desarrolladores. El problema es la lógica de programación, no el entorno sobre el que se trabaja.
- Respecto a bajarse programitas de internet, eso es problema del sysadmin. Un buen proxy web configurado con cariño te soluciona la papeleta. Junto con un buen antivirus y unas políticas de permisos de usuario restrictivas (que no prohibitivas), ya no tendrías que preocuparte en demasía sobre la infección de la red o, [JUAS!] "pérdida de datos de tres días" (¿por cierto, dónde quedan los backups y esas cosas?).
- En lo que SÍ estoy deacuerdo es en lo referente a las librerías. Es triste, pero pasa. En fin...
- "...puntos de control estandar de la instalacion..." -> ¿? ¿HOLA? ¿alguien le encuentra sentido a esta frase?
"lo malo de internet es que cualquiera puede escribir cuatro chorradas y que parezcan algo con fundamento." -> Pues aplícate el cuento campeón.
#12 A tí no hay ni por dónde cogerte. Lo que defiendes es precisamente la actitud que hay que cambiar si se quiere mejorar la calidad (no el beneficio, claro) del producto final.
Mientras escribía una respuesta a tu comentario de aprox. 4-5 líneas me he dado cuenta de que estaba rebatiendo TODO tu comentario. Frase por frase. No merece la pena. Considero que estás taaaan equivocado que es mejor dejarte seguir viviendo en tu mundo particular: aquel en el que un mecánico de un taller importa menos, sabe menos y es menos capaz, en definitiva, que el administrativo que imprime las facturas a los clientes, o que el comercial que vende un cambio de aceite que el cliente no necesita (o le vende al cliente que, por supuesto, su coche saldrá de ahí con un bonito condensador de fluzo), sólo para aumentar el beneficio. Suerte en la vida, figura!
#13 Jode..., otro. Amos a ver... Los saltos de línea no son diferentes para cada SO, sino que dependen de la codificación del fichero/editor que uses. Obviamente, si estás en windows y programas para una web colgada bajo linux, coño, usa un puto editor que tenga soporte para la codificación unix! Hay decenas. Algunos muy buenos. E incluso alguno gratuito. Cualquier programador que no sea un jodido nooob podrá lidiar con ello sin problemas. No necesitas un programa de terceros que controle eso (p.ej. Vagrant), sino, simplemente, tener dos dedos de frente. Pero, claro, hay gente a la que no le llega...
#14 Sí, los sistemas de virtualización han mejorado una burrada. Peeero, aún así, SIEMPRE funcionará más lento virtualizar que no hacerlo. Por una sencilla razón, por mucho que mejore el software, el mayor cuello de botella es el hardware. Que no se te olvide que estás usando el hard de un pc para hacer funcionar 2. Por mucho que funcione bien, NUNCA podrá igualar el rendimiento de un pc dedicado (aunque sea una mejora mínima).
Usando un símil con el área de la construcción, personalmente opino que el problema aquí es la extendida creencia de que la que levanta un piso es la constructora, cuando, en realidad, sin los arquitectos, albañiles y demás currelas, una constructora sólo es una reunión de administrativos. Los primeros sin los segundos podrían construir un edificio perfectamente, mientras que viceversa no.
No niego la utilidad de los gestores, simplemente pongo muy en duda su posición superior de responsabilidad (y, por ende, de sueldo y capacidad de decisión).
Considero que al que le sobra (y muuucha) soberbia, es al gestor, no al desarrollador. Más que nada, porque el que sabe lo que hace es éste último, mientras que el primero vive de lo que saben otros, cual mero parásito, escudándose en supuestas habilidades de gestión de personal que le permiten cobrar un sueldo netamente superior mientras les dice a los auténticos [magos] currelas, que le dan mil vueltas, qué deben hacer y cómo.
Por último me gustaría pediros, a los que no estén deacuerdo conmigo, que en vez de / además de un negativo respondan a mi comentario. Qué le voy a hacer si soy fan del método Socrático... (^-^)
#18 Te sorprendería saber cuantas veces alguien edita un archivo de configuración de un servidor Linux con el Notepad de Windows y se jode la marrana. Eso o un Script Bash.
Está claro que cualquier IDE decente va a utilizar la codificación y los saltos de linea que tu le digas, pero siempre hay cosas que se editan más rápido sin un IDE, y si no tienes un editor de texto potente como Notepad++ o Sublime Text, te tragas la codificación de los saltos de linea que al editor le de la gana.
¿Que con sentido común se arregla? Por supuesto, pero teniendo a todos desarrollando en el mismo entorno también se arregla. Y lo segundo suele ser más fácil de conseguir en cualquier empresa medianamente grande.
Por cierto, nosotros tenemos licencia de uso de ABCPdf 7, el cual no es compatible con Windows 8. Es decir, que todos los desarrolladores que tienen Windows 8 no pueden probar sus programas en local a no ser que se bajen la versión de prueba, cambien los DLL y las referencias en su proyecto, lo prueben todo y se aseguren de que no hacen un commit con el nuevo dll (que será un dll de una licencia de prueba). Chupado vamos.
#19 No, si soy consciente de que es una práctica extendida.
En cuanto al sentido común me refiero al que te dice que uses "un editor de texto potente como Notepad++ o Sublime Text". Eso, para mí, es tener sentido común; o un nivel mínimo, si quieres llamarlo de otra forma.
#18 " Sí, los sistemas de virtualización han mejorado una burrada. Peeero, aún así, SIEMPRE funcionará más lento virtualizar que no hacerlo. Por una sencilla razón, por mucho que mejore el software, el mayor cuello de botella es el hardware. Que no se te olvide que estás usando el hard de un pc para hacer funcionar 2. Por mucho que funcione bien, NUNCA podrá igualar el rendimiento de un pc dedicado (aunque sea una mejora mínima)."
. Si puede con un juego así, para un PC de oficina es algo de risa. Para programar, Linux tiene una función especial en el kernel para compartir paginación de modo bastante eficiente permitiendo ejecutar más maquinas virtuales (ocupando más RAM que la física en conjunto), sin ralentizarse.Claro está, pero como digo, KVM/XEN más virtuazaciones por hard+PCI passthrough en caso extremo te permite hasta esto:
Y si le metes a cada guest ZRAM, puedes multiplicar el número de hosts por un 1,5 sin problema. Con un i7 y 12 G de RAM podrías ejecutar 30 hosts cada uno a 512 de RAM de uso por ejemplo, para programadores.
Claro está, el SO hosts debe estar muy preparado para ello y ultratuneable (quitar morralla, drivers, servicios, tunear el scheduler, ZRAM)... No, Windows Server con HyperV no se le acerca ni de coña. Aún tenemos Xen que destruye en rendimiento al hypervisor de Windows.
#21 Vale, reconozco que me ha impresionado.
Aún así, aún tendría algo que puntualizar:
Él usa el siguiente hard: "I have a an 8core amd processor [n.t:AMD FX 8150] with 16GB ram and two graphic cards. 4cores, 8GB ram and the high end graphic card is solely for the virtualized windows." (http://michaelmk.blogspot.co.at/2012/06/gaming-on-gentoolinux-via-xen.html)
En donde trabajo, tienen una amplia cartera de clientes (entre 30 y 50, no trabajo en toooodos los proyectos, y no me apetece contar la lista de bases de datos de nuestro server), algunos son empresas internacionales de renombre. Resulta que no sólo almacenamos ciertas web's en desarrollo, sino que en algunos casos también alojamos web reales (con su par de servers extras virtualizados, claro) en éste pc: Core2Quad Q6600 - 3GB RAM - Gráficos integrados de intel.
Y no somos de los que tienen peor hardware, créeme. Vamos, que tenemos un pc de 8 núcleos a 3,6Ghz frente a otro de 4 a 2,4Ghz; 16GB de ram DDR3 frente a 3GB DDR2 y una gráfica integrada frente a DOS dedicadas. Y si te hablo de los pc's que usamos para programar, ni te cuento...
Vamos que el ejemplo que has puesto, difícilmente se podría aplicar a un entorno empresarial medio. Entre otras cosas porque dudo que el empresaurio autorice la compra de semejante bestia pudiendo, por el mismo precio comprarse varios mucho más limitados y en los que virtualizará igualmente. Que es la situación actual de la que nos quejamos.
Sé que con la configuración hard-soft correcta y metiendo horas poniéndolo a punto y tal, se podría conseguir un sistema cuya pérdida de rendimiento tienda a 0.
Pero también debes admitir que se trata de un escenario ideal que está bastante lejos de la realidad empresarial actual.
En fin, que es obvio que si el hard es extremadamente potente, se puedan emular varios SO sin apenas pérdida de rendimiento. Es como si en la máquina del tío este virtualizases 300 pc's con MS-Dos. Pues irán como un tiro, sí, pero no significa que sea la opción correcta a la hora de programar.
En resumen, te ofrezco unas tablas:
Sí, la virtualización es más potente de lo que había considerado en un principio, permitiendo, en ciertos casos, una pérdida de rendimiento casi imperceptible; pero no, no considero que sea aplicable a los entornos de desarrollo pre-históricos de las empresas pequeñas/medianas.
#22 Hombre, no hablo de MS-DOS, pero Xen es otra cosa, como digo. Y no con precisamente con entornos capados. Ten en cuenta que las X se pueden exportar en local sin notarse pérdida, o usar Xen/KVM + VNC + QXL para aceleración 2D util para los entornos de desarrollo que usen IDE´s de escritorio.
Todo es probar.
#18 O sea, que por muy fan del método socrático que eres (que no sé si tienes muy claro lo que quiere decir, Sócrates enseñaba a base de preguntas, no de respuestas), quieres que se te responda, pero tus propias respuestas tienen más de soberbia mal entendida que de contenido.
Y tus símiles son igual de incorrectos. ¿Los ingenieros son los mecánicos de tu primer ejemplo? ¿Reparan el software o lo crean? ¿Y los diseñadores? ¿Los expertos en seguridad y testeo? ¿Los que planifican cuántos coches se construyen? ¿Los que lo montan? ¿Los que los venden? ¿Los que coordinan? Desde tu punto de vista, muy de ingeniero, el único importante es el mecánico... y eso sería así si se tratara de conseguir "el mejor" coche. Pero de lo que se trata es de conseguir "el coche mejor vendido". Sin eso, las empresas no funcionan, y ni los ingenieros se ven pagados a fin de mes.
Déjame que te explique cuál es el punto de vista del que ve un poco más allá de su propia esfera de trabajo.
Yo trabajo creando videojuegos. Cuáles o cómo no importa mucho. Mi trabajo es el de dirigir el proyecto y el producto. Soy el último garante y responsable de la calidad final y del resultado. Dirijo al equipo al completo.
No sé programar ni mucho menos tan bien como el peor de mis ingenieros. Sé lo justo para entender su trabajo, dónde puede haber dificultades y qué cosas son posibles y cuáles no
No sé dibujar o hacer arte ni mucho menos tan bien como el peor de mis artistas. Sé lo justo para valorar qué se puede hacer y cuánto esfuerzo puede costar.
No tengo muchísima experiencia directa en QA, o en diseño de UI, o en CS, o en CM, o en cualquiera otra de las cosas que hacen falta para publicar un juego hoy en día. He hecho de todo eso, pero no soy un especialista en ninguna de esas áreas.
Mi especialidad es el diseño del producto y la gestión. Es decir, la coordinación de todas las partes que he citado, y más, para sacar un producto al mercado que nos haga ganar dinero y mantener la empresa a flote.
El problema con tu visión es que crees que por poner los ladrillos del producto sabes más de él que nadie. Lo siento pero no es así. Los ingenieros cumplen un papel muy importante, pero ni mucho menos es el único valioso. Sin el diseñador, no hay una visión, ni una idea de cómo interactuar con el jugador. Sin el Product Manager, no hay idea de cómo ha de diseñarse el producto para que tenga éxito en el mercado, atraiga al jugador y sea sostenible en el largo plazo. Sin el especialista en UI, no hay una interfaz de usuario inteligente y sensata. Sin los artistas no hay atractivo gráfico. Sin los testeadores, no hay control de la calidad, sin los producers no hay gestión de fechas, de tiempo o de costes. Sin CS o CM, en fin, no hay soporte de los jugadores después de lanzamiento o comunicación con ellos...
Y sin los que gestionamos toda esta maraña de intereses entremezclados, no hay empresa que sobreviva. Te guste o no, de eso se trata en última instancia. De conseguir competir y entretener y proporcionar diversión a quién está ahí fuera, esperando nuestros productos y dispuesto a criticarlos con saña de mujer traicionada si no cumplen sus completamente inalcanzables expectativas.
Esa capacidad de funcionar como piezas en un rompecabezas y mostrarse dispuesto a escuchar, no sólo a dictar sentencias basadas en su condición de ingenieros, es lo que les falta a muchos desarrolladores (Y a muchos artistas, producers, QA y demás, pero éstos al menos admiten que pueden estar equivocados de vez en cuando). Si tu post es la actitud que tienes en general, tú eres uno de esos ingenieros con los que siempre preferiré no tener que trabajar
#25
Pues sí, me equivoqué al mencionar al método socrático. Gracias por recordármelo. No obstante, sigue siendo completamente irrelevante. (te suena aquello de que cuando nosequién señala la luna....)
- "pero tus propias respuestas tienen más de soberbia mal entendida que de contenido": Vaya, acabo de descubrir dos categorías de soberbia: la mal entendida y la... ¿bien entendida? ¿Pero tú te lees? Puedes entender mal el concepto de soberbia, pero no puedes tener soberbia mal entendida. lol. Y ya que estamos podrías explicarme también qué entiendes tú por contenido, porque que en 862 palabras no haya contenido.... Eso sí me preocupa. A ver si se me está olvidando escribir...
Volviendo al tema que nos ocupa, intentaré aclararte mi comentario:
- ¿Los ingenieros son los mecánicos de tu primer ejemplo? : Sí, esa era la idea, aunque habría más puestos, claro (como un diseñador, por ejemplo). Pero no el de gestor, por supuesto.
- ¿Reparan el software o lo crean?: Da igual. Son los que saben repararlo y crearlo y lo reparan y crean. Lo que importa es que saben realizar y realizan efectivamente el trabajo en sí. Lo que viene siendo literalmente la mano de obra.
- ¿Y los diseñadores?: Eeeemmm, pues lo mismo que los ingenieros... Ellos no mandan a otros que hagan algo. Ellos lo HACEN. No importa cómo se llame su puesto.
- ¿Los expertos en seguridad y testeo?: Joe, ¿vas a preguntar por todos los puestos de trabajo del mundo? Leete la pregunta de arriba.
- ¿Los que planifican cuántos coches se construyen?: No, éstos no. O no siempre. Generalmente los que dictan la carga de trabajo y el nivel de producción (sin participar en ello), suelen estar más pendiente de la consecución de objetivos y el beneficio que de la calidad. Vamos, que con tal de llegar al límite que ellos ponen se la sopla lo demás.
- ¿Los que lo montan?: Y vuelta la burra al trigo.... léete lo de los diseñadores otra vez.
- ¿Los que los venden?: NO. Yo no veo a un comercial pasando casa por casa (que tampoco quisiera, ojo), y eso significa que el cliente ya está predispuesto a comprar cuando entra en un concesionario. El vendedor sólo consigue que se lo compre a él, aunque su producto sea peor que otro. Si el coche fuese el mejor, no haría falta un esfuerzo comercial que implicase a un experto en
engañosventas.- ¿Los que coordinan?: No. Ni de lejos. vuelve a leerte, por tercera vez, la pregunta del diseñador, majete.
- "Desde tu punto de vista, muy de ingeniero, el único importante es el mecánico": No, hombre no, tampoco es eso. Pero sí es, desde mi punto de vista, MÁS importante que los gestores y compañía. Sin duda.
- "Pero de lo que se trata es de conseguir "el coche mejor vendido". Sin eso, las empresas no funcionan, y ni los ingenieros se ven pagados a fin de mes." Ahí, ahí. ahora llegamos a la miga del asunto. Precisamente defiendo que la política de buscar el beneficio puro, poniendo las "necesidades" de la empresa por encima de las de sus empleados (me refiero a los curritos, como he intentado explicarte en el tochaco superior) es un completo error e innecesario. Je,je,je... en cuanto a lo de que se ven pagados a fin de mes.... si la empresa repartiera a partes iguales el total del beneficio, creeme que muchos estarían dispuestos a cobrar menos que eso. Seguiría siendo mucho más que lo que cobran ahora. Las empresas NO se hundirían. Es un miedo recurrente, pero no pasa nada por ganar menos. Esta sociedad busca el crecimiento por el crecimiento. Con ansia viva. No pasa nada si no creces un 1,5% anual. Relajad el ojete...
En resumen: para mí siempre será mucho más importante crear el MEJOR programa que el más vendido. Y sinceramente creo que como modelo empresarial es perfectamente viable.
- "Déjame que te explique cuál es el punto de vista del que ve un poco más allá de su propia esfera de trabajo.": A ver, ilumíname, caballero sin soberbia...
- "No sé programar ni mucho menos tan bien como el peor de mis ingenieros. Sé lo justo para entender su trabajo, dónde puede haber dificultades y qué cosas son posibles y cuáles no": Te contradices. Si la primera frase es cierta, es IMPOSIBLE que se cumpla la segunda. Estoy seguro de que no tienes ni puta idea de las dificutades y posibilidades. Siempre y cuando esas dificultades no te dificulten tu trabajo o las previsiones de producción. Ahí seguro que las conoces. Y también cuando esas posibilidades den beneficio. Ey!, que no lo digo yo, lo has dicho tú: "...se trata es de conseguir "el coche mejor vendido""...
- "No sé dibujar o hacer arte ni mucho menos tan bien como el peor de mis artistas. Sé lo justo para valorar qué se puede hacer y cuánto esfuerzo puede costar.
No tengo muchísima experiencia directa en QA, o en diseño de UI, o en CS, o en CM, o en cualquiera otra de las cosas que hacen falta para publicar un juego hoy en día. He hecho de todo eso, pero no soy un especialista en ninguna de esas áreas. ": Además de contradecirte, te repites... Pasemos a algo que no hayas dicho ya...
- "Mi especialidad es el diseño del producto y la gestión. Es decir, la coordinación de todas las partes que he citado, y más, para sacar un producto al mercado que nos haga ganar dinero y mantener la empresa a flote.": Te escribo lo que he entendido: "Mi especialidad es mandar a otros para que me hagan ganar más dinero". Pues que vida más triste. Además vuelves a hablar de la empresa como si fuese... no sé, oxígeno... ¿Sabes porqué me la sopla tanto que la empresa vaya bien o regular? Porque sé hacer el producto, y puedo hacerlo en otra o ser la empresa y hacerlo por mi cuenta. Lo que me falta es el presupuesto, no las capacidades. ¿Puedes decir lo mismo? ¿Podrías ganar dinero gestionandote sólo a tí mismo? Porque yo sí podría ganar dinero programando sólo. Al igual que otras personas en otros puestos (ver pregunta de los diseñadores (4º)). Pero claro, siempre es la misma cantinela: ganar, ganar, GANAR!
- "El problema con tu visión es que crees que por poner los ladrillos del producto sabes más de él que nadie. Lo siento pero no es así.": Por supuesto que sí es así. No sé dónde está el problema. El que pone el ladrillo sabe más de él que el capataz que no sale de su oficina/despacho. Pero eso pasa en todos los aspectos de la vida. ¿Nadie te lo había dicho aún?
- "Los ingenieros cumplen un papel muy importante, pero ni mucho menos es el único valioso.": Te lo vuelvo a decir, que parece que no lo comprendes. No digo que sea EL MÁS valioso, pero sí MÁS valioso que otros puestos como podría ser el tuyo.
- "Sin el diseñador, no hay una visión, ni una idea de cómo interactuar con el jugador. Sin el Product Manager, no hay idea de cómo ha de diseñarse el producto para que tenga éxito en el mercado, atraiga al jugador y sea sostenible en el largo plazo. Sin el especialista en UI, no hay una interfaz de usuario inteligente y sensata. Sin los artistas no hay atractivo gráfico. Sin los testeadores, no hay control de la calidad, sin los producers no hay gestión de fechas, de tiempo o de costes. Sin CS o CM, en fin, no hay soporte de los jugadores después de lanzamiento o comunicación con ellos...": A ver, por partes:
> Diseñador: Nunca he menospreciado este puesto. Vuelve a leer mis comentarios. El diseñador sí genera un producto final con sus propios medios.
> Product Manager: El ejemplo perfecto de un puesto creado de la nada y perfectamente prescindible. Me voy a tomar el lujo de seleccionar las palabras más relevantes del ejemplo concreto: 'exito/mercado', 'atraiga' y 'sostenible'. Y ahora te lo traduzco a lo que entiendo yo: 'DINERO', 'MAS_VENTAS=MAS_DINERO' y 'MAS_DINERO_POR_MUCHO_TIEMPO'. En el modelo empresarial que defiendo, su figura es completamente prescindible.
> Especialista en UI: Obvio que es importante. Más en tu rama de negocio. (vuelve a leer la pregu... bueno, te pongo las que llevas y tú ya te apañas, que empieza a ser demasiado repetitivo: 5º)
> Artistas: Hombre, esto lo englobaría junto con diseñadores, pero estamos en el mismo caso. Trabajan sobre el producto, así que: (6º)
> Testeadores: completamente prescindible. Saca betas gratis con un feedback simple en vuestro sitio web y los propios usuarios realizarán el trabajo. Mismamente el proyecto Half-Life: Black Mesa hizo algo parecido. Sacó la beta habiendo probado lo justo, y en el foro de su web, los usuarios notificaban los bugs.
> Producers: Bufff, de verdad, que tirria me dan todos esos puestos con nombres en inglés. No salvaba ni uno. Entiendo que haya que controlar el gasto, pero, de toda la vida, eso lo tendría que hacer un contable. Y en cuanto a las fechas y tiempos... la necesidad de controlarlo surge del modelo empresarial que tú defiendes. 'Si saco el producto antes ganaré más' (porque ya me dirás que mas dará sacar un juego este año o al siguiente. Incluso mejor, las plataformas tendrán más potencia e irá más fluido [es un ejemplo exagerado, no lo tomes literalmente]). 'Si fabrico cada producto en menos tiempo, fabricaré más en el mismo tiempo y ganaré más'. Desde mi punto de vista, esta actitud es, no sólo moralmente rechazable, sino aborrecible. La gente que piensa así, sinceramente, me da pena.
> CS/CM: Puf! pues si que estamos. Déjame decirte que soy jugador aficionado. Pero que muy aficionado. Además, conozco auténticos jugones que honran la palabra Gamer. Y aún estoy por encontrar un juego con un soporte o comunicación decentes. A mis espaldas llevo miles de horas en decenas de juegos. A éstos CS/CM, no sólo les diría que sobran en mi modelo empresarial, si no que considero que lo hacen incluso en el tuyo. Ya se pueden aplicar en sus curros, porque ése es un área con severas deficiencias.
- "Y sin los que gestionamos toda esta maraña de intereses entremezclados, no hay empresa que sobreviva. Te guste o no, de eso se trata en última instancia." Ooootra vez con el dichoso beneficio. Pues nada, oye, como si quieres darte de cabezazos en la pared. No hay más sordo que
#27 ""Esa capacidad de funcionar como piezas en un rompecabezas y mostrarse dispuesto a escuchar, no sólo a dictar sentencias basadas en su condición de ingenieros, es lo que les falta a muchos desarrolladores":"
Es lo que tiene, ellos saben como funcionan las cosas y tú apenas conoces un 1%. Capacidad de producción, lo llaman.
"No sé programar ni mucho menos tan bien como el peor de mis ingenieros"
Si sabes programar ALGO, aunque sea un mínimo, deberías ser totalmente consciente de todos los riesgos que hay a la hora de programar, en cuanto a rendimiento, bugs, etc... y por lo tanto no andarías diciendo tantas tonterías.
De hecho, si alguien tiene conocimientos superiores a los míos lo que menos haré será discutir con el en cuestiones técnicas si éste me dice que lo que intente hacer un programa es inviable por diseño interno.
#29
#31
#30 No sé si el problema es simplemente de no entender qué hacen los demás o es una cuestión de creer que sólo con ingenieros puede funcionar el mundo... Que yo no sepa programar al nivel de alguien que lo tiene como especialidad no quiere decir que vaya a lanzarme a decirle cómo tiene que hacer su trabajo. Ni mucho menos. Pero sí quiere decir que se necesitan tener ciertos conocimientos si se quiere poder coordinar bien esa parte de un proyecto con las demás.
De nuevo, es una cuestión de falta de perspectiva. Me explico: Estamos diseñando un añadido a un juego que lleva funcionando ya tiempo en el mercado. Digamos que esta nueva parte es una manera para los jugadores de competir-colaborar entre ellos. ¿Quién creeis que debe tomar las decisiones sobre cómo crear este nuevo elemento?
-Si la decisión la toman sólo los ingenieros, el resultado será muy eficiente y elegante, pero poco atractivo para el usuario final y probablemente más costoso de lo necesario.
-Si la decisión la toman sólo los product managers, el resultado dará muy buenos resultados económicos pero no será divertido de jugar y el diseño será completamente simplista y poco repetible en el futuro.
-Si la decisión la toman los diseñadores, el resultado será muy divertido de jugar, pero más complicado de lo necesario, difícil de crear y de mantener y una pesadilla de código.
-Si la decisión la toman los creativos-artistas, el resultado será muy bonito. Y nada jugable.
-Si la decisión la toman sólo los ejecutivos, el resultado será injugable y todos los demás partícipes del proceso de creación estarán cabreados
¿Veis el problema? Por supuesto que en determinados productos, el ingeniero se basta y se sobra para crear algo perfecto, y por supuesto que la filosofía de "lo mejor" es aplicable a ciertas cosas. Pero en un mundo con recursos y tiempo limitados, y complejidades cada vez mayores, esto es cada vez menos posible.
¿Crees que el trabajo de los coordinadores es prescindible? Trata de crear un juego de tamaño medianamente decente y te encontrarás con muchos problemas.
Para terminar, el problema es básicamente de ego. El trabajo de un coordinador, un producer, un ejecutivo o como quieras llamarlo es el de contener todos los egos que hay presentes en un producto (desde el director creativo hasta el último programador) y conseguir sacar el mejor producto posible. Y ésto no es en "este país", #29. Hace una década que no trabajo en España, ni en empresas españolas.
#32 En Valve no hay eso que tu llamas "producer" o ejecutivo.
#33 Cierto, pero...
- Siempre hay alguien cuyas decisiones tienen más peso que las de los demás. Lo que pasa es que sus "directores de proyecto" cambian a cada proyecto nuevo. Es un buen sistema, la verdad.
- No se puede tener la compañía perfecta sin la gente perfecta para ella. Valve pone mucho esfuerzo en reclutar sólo a gente que cuadra con esa peculiar cultura.
- Valve es sólo una compañía en una industria en la que hay cientos. Es un buen ejemplo, y ojalá muchas más fueran así, pero dudo mucho que el modelo de Valve sea el futuro de todo el sector.
#25 (...continuación)
el que no quiere oír. Tú sigue con esa filosofía, a ver si en un par de años te vemos en la lista forges, espabilao.
- "De conseguir competir y entretener y proporcionar diversión a quién está ahí fuera, esperando nuestros productos": Muy bonito como eslogan, pero ya has dejado suficientemente claro que lo que te motiva en tu trabajo, no es hacerlo mejor, si no conseguir más beneficios "para que la empresa siga a flote". Como si fuera un Titanic recauchutao. Aunque bueno, mejor pensado, en estos tiempos, sería algo parecido...
- " y dispuesto a criticarlos con saña de mujer traicionada si no cumplen sus completamente inalcanzables expectativas.": Eeehhh, no, no los entiendes bien, lo que pasa es que no tienes ni idea de cuáles son sus expetctativas (seguro que en tu empresa hay alguien que dice qué quieren los usuarios, en vez de escuchar directamente a los usuarios). Ah!, y si lo critican es porque es un MAL producto. Ahora bien, da beneficio, eso seguro. Pero es un MAL producto. Que no os extrañe si seguís con tu modelo de negocio como filosofía.
- "Esa capacidad de funcionar como piezas en un rompecabezas y mostrarse dispuesto a escuchar, no sólo a dictar sentencias basadas en su condición de ingenieros, es lo que les falta a muchos desarrolladores": Te traduzco a lo que he entendido: 'a los desarrolladores les falta callar y hacer lo que yo digo'. Menudo problemón que tengan personalidad, capacidad de juicio y puedan rebatir tus peticiones/propuestas porque saben más que tú de lo que hacen. Y no lo digo yo, ésto último lo dices tú: "No sé programar ni mucho menos tan bien como el peor de mis ingenieros". Pues lo dicho, menudo problemón, eh?
- "(Y a muchos artistas, producers, QA y demás, pero éstos al menos admiten que pueden estar equivocados de vez en cuando).": ¿Y no será, alma de cántaro, que igual, y sólo igual, están equivocados en menos ocasiones, en las que disienten con tu punto de vista, que los artistas, producers, QA, etc... ? ¿Se te ha pasado dicha posibilidad por tu humilde cabecita? ¿O qué quizá estos últimos también cojeen de tu mismo pié? ¿O acaso consideras soberbio a cualquiera incapaz de estar de acuerdo contigo en algo?
- "Si tu post es la actitud que tienes en general, tú eres uno de esos ingenieros con los que siempre preferiré no
tener que trabajar ": Coño!,636 palabras y es la primera frase en la que coincido contigo. Y yo tan a gusto. Pero iría más lejos: preferiría no tener ni que cruzarme por la calle con cualquier persona que siga tu filosofía, donde el beneficio es el único Dio$ y el gestor su profeta.
Bueno, ya he rebatido tooodo tu comentario. Hasta que no lo has conseguido no te has quedado tranquilo, eh?
Pues ahora te lo empollas bien poque no pienso responderte a ningún otro comentario.
Mientras escribía este muermo me he dado cuenta de que nuestras posturas difieren en la base, y son puramente irreconciliables por su naturaleza opuesta. Y como no quiero odiar más a la gente como tú, ni cabrearme a lo tonto, ni perder más tiempo con quien no lo merece, no responderé a ningún otro comentario tuyo en esta noticia que sea alusivo a los aspectos que ya hemos tratado.
Hala!,... por la sombra!
#28 ""No sé programar ni mucho menos tan bien como el peor de mis ingenieros".
Sólo por eso #28 se tendría que quedar calladito y dejar trabajar a los que saben y no los que tienen nombres "cool" en inglés con trabajo automatizable (todo lo económico se puede calcular), que muchos no saben ni hacer la o con un canuto.
" Sé lo justo para entender su trabajo, dónde puede haber dificultades y qué cosas son posibles y cuáles no":"
La madre que lo parió. Entonces, yo puedo decir que sé lo justo sobre medicina y orientar al cirujando que me va a operar, ¿no? . Madre de dios, pero cuanta morralla sobra en éste pais.
#c-29" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1921663/order/29">#29 Aaaamen! No podría estar mas de acuerdo...
...pero corrige el # 28, que me apuntas a mí y no a # 25! :__(
Al autor igual le parece una tortura, pero que intente dirigir ÉL un equipo de desarrollo no muy grande, digamos 20 pepitos, donde cada uno usa el IDE que le sale de sus respectivos, unos en equipo windows, otros en mac y otros en su calculadora casio (que gestione ÉL el mantenimiento de los equipos, las licencias necesarias,..) y que luego se encargue ÉL de hacer unas pruebas conjuntas integrables y todo eso, dejando que cada uno se instale lo que le salga del pito (uy, me he bajado XXXX de internet y me ha metio un troyano que ha borrado el curro de 3 dias!!!), creando cada uno sus librerias para no reaprovechar el codigo de otros (MALO!!!! SI NO Lo hago yo no es guenooooo) o que obliga a pasar por puntos de control estandar de la instalacion....
lo malo de internet es que cualquiera puede escribir cuatro chorradas y que parezcan algo con fundamento.
#9 Te voto positivo por: lo malo de internet es que cualquiera puede escribir cuatro chorradas y que parezcan algo con fundamento.
Es increíble la gente que se cree que la respuesta a todo esta en google refinando la búsqueda. Leer manuales, documentación, etc. no va con ellos.
Forzar el uso de Windows. O de Linux. O de Mac. Que cada uno utilice con lo que esté más cómodo y sea más productivo, ¿no?
NO. Ni de coña. Que siempre está el típico notas que hace cambios en Windows con un editor de texto normal y corriente (o con un IDE sin configurar) y luego peta en desarrollo (o en otra máquina) y no tienes ni puta idea de que es lo que está pasando. Los saltos de linea son diferentes dependiendo del sistema, y eso es un problema.
Estoy de acuerdo en que cada uno use el SO que quiera, pero que pongan algo como Vagrant encima.
"Las eternas máquinas virtuales. Sí, ahorras mucho en hardware pero todo se vuelve mucho más lento y engorroso." Con KVM ni de coña, sobre todo si el que virtualiza es un Linux con un kernel muy reciente.
#13 Exacto. Y no soy programador, pero sí me ha pasado con archivos de configuración.
#0 Si programas en Dreamweaver no eres un desarrollador
#2 Eso es lo que dice la noticia
#2 ¿Puedes desarrollar un poco tu frase? Porque como tu mismo dices "si programas", ergo desarrolla, ¿o no?. No habras querido decir "Si usa Dreamweaver no eres un desarrollador"
#8 Si, mucho mejor como tu lo dices
#2 Si eres desarrollador y te obligan a usar dreamweaver es una tortura.
Aquí están más completitas (pero en inglés):
http://www.infoworld.com/d/application-development/16-ways-torture-developers-215773
hombre, filosofía no se, pero valve anuncia el hl3 y y tienes a todo dios detrás buscando la primicia.
Tan mal no les va. Y bueno, es una compañía de muchas pero con steam.
Falta una que siempre me comenta un compañero, obligarte a utilizar software traducido. Porque "Adjuntar a un proceso" es sencillamente ridículo, entre otras grandes perlas.
¡Ah! ¡Los problemas del primer mundo!