Engineering vs. Development

BRAINSTORMING - DO NOT READ -

Taming Software Engineering for Developers From prototypes to Production

-Life Cycle Procedures Branchs Version Control tagging Fault Tolerance - what works when something fails separar trader de market run, separar stats. Manolitics vs. Services ej. S.O. Time to production Fault tolerance catching errors Monitoring response time in services logging Mantras on Production First don't break As in Factories, don't make unsafe repairs (hot) Testing Stress tolerance Reusable Components Core business vs. Expanded ecosystems Typing Architecture for Production Refactoring Target Readers Small Auto Governed software developers Going to Production Prepare for backpedal Backups procedure checklists Bulk functionality Non functional requirements Hacky code Every line needs maintenance Teams and Personality Matching Attention to detail person: test, pre, pro Creative and Fast minds: closer to prototyping Standard practices Performance problems Balancing with complexity Making developers life miserable vs. good engineering What piss off engineers vs. what piss off developers crappy code, spagetti bad OO design bad Arquitecture bad Procedures Faulty or inconsistent behavior Change Fast vs. Slow Don't couple functionality that change fast with funcitonality that change slow (the fast will break the slow) Code and Databases (structures, content size) Event Tracking and Tracing Whats going on, what fails, what works Architecture Types on Prototype vs. Production
CONSULTAR AMIGOS / COLEGAS Problemas de Ingenieria Testing goes deeper branching gets deeper non functional requirements goes deeper deployment infraestructure gets allocated deployment environments get designed and prepared ocassional hard fails gets forbidden closed for modification to avoid design extension, deprecating old design IoC and components mobility lessions from working with productive systems hot fix at design time vs. production time NOT just a protype Mantras if it is not stable running is just a prototype (Bart writing on the board) if it is not live is just a prototype if no one is using for real use is just a prototype if no one depends on it, is just a prototype if no one gets pissed of when it hard fals, it is just a prototype if it goes off line for long time when it hard fails, it is just a prototype if no one outside the team is using it, is just a prototype Working on Protypes are fun, production software is boring If the software includes sketchy or half baked functionality, it should be marked as experimental, should not go to production do not send to production branch anything sketchy batch changes to production to allow manual, thorough testing programmers shall not play with production, hay tabla (simpson) programmers shall not play with preproduction, hay tabla (simpson) matching personality keep fast, creative, cheerful developers, kids at protopying , test ideas. keep TOC develeopers, to details, and adult people, family guys, at production support, testing and maintenance. dilbert strips, sympson memes, batman memes freeze functionality once you decide to go live, top priority is stability and polishing avoid unsafe refactoring, after deciding to go live someone else should try it border cases give it to try it to mean people do not be so naive to rewrite from scratch something you have in production you will loss tons of details and chatch ya code do not allow the code to go bad do not mix functionality, even if it is not normal flow handling, isolate code in meaningful functions to avoid lossing semanthic info force people to comment non trivial code force people to comment DO NOT TOUCH code if method semanthics is not clear, it's better to refactor to split mixed behaviors do not add any non MVP functionality at the expense of postponing go live testimonials from developers about productions epic fails missing keys, foreing keys etc, is ok in a prototype, in production it is not keep track of storage structure changes, diffs modules and components that you need in production but depend on production quotes from outside computing (literature, philosophy, etc) prepare for the worst, be defensive on core functionality and MVP dependencies. automate MVP testing prepare for rollbacking storage in protopyping vs. production cover simil Compiler Design book (el del dragón) Treat like a frog your prototype and like a prince your productive system The size does not matter (at least in software), you can have a hundred line production software and a hundred thousand prototype not perfect, acceptable. Tapizados bolivianos, un punto salido, para recordar que solo dios es perfecto. security, internet the ocean or the pond you have a prototype, grafico de torta, what you think you have, what you have (mejor: foto de edificio casi terminado vs. foto de rancho a medio caerse) decoupling components and instance failure: one user failure should not affect others, one complex component failure should not make base components fail. compartimientos estancos en barcos single points of systemic failures component criticality building vs. creating for non core tools and systems over designing architecture when prototyping, vs. short sight designing when developing product handling failures: tracking, informing to whom, and what: system admins, devs, users, infra admins fail tolerance testing, random monkey at netflix proper protocol to handle errors: avoiding chenobyl fails lessons from other engineering domainsç respawning services when recoverable and how much keeping users work when failing (the boats at titanic) los pilotos de prueba en la aviacion horas de vuelo estables building stable systems aviacion: rapid testing como hacer un planeadorque despegue pedaleando how is right ? developer or engineer: depends, also, need of communication, allow expert developers to explore alternative prototypes and express avoiding failures for lack of resources (engineers x-times resistant on risky pieces, the gas tank pressure resistance) blackboxing: classes and functions, vs. mathematicians/phisics style build for fail vs. build prototype, el mono loco. titanic y compartimientos estancos - cuantos componentes pueden fallar hasta fallo sistemico simulacion de fallas y las plantas atomicas error humano y disponibilidad de servicios: qué pasa cuando un operador se equivoca ? qué pasa cuando se dispara la orden incorrecta ? es aceptable un timer antes de hacer la operacion real (ej. gmail con plugin que retrasa el envio de correos).

orden de resolucion de problemas: ingenieria,arquitectura,hardware,soluciones standard,programacion,hacking.

publico objetivo: petit engineers, hobistas, rogue programmers, small auto governed teams, lustkraft guys. no crap redaccion, nada de buzzwords

testing, cuando es demasiado, preferencia por el testing grueso, retrasarlo tanto como sea posible, hasta fijar arquitectura, funcionalidad, requesitos adhoc que aparezcan.

diccionario no crap de ingenieria app ecosystem: additional software needed to make the thing useful.

if you knocked the wrong door: you want to learn big engineering, not la petit one: ideas de como aprender (basicamente entrar a la industria , prestar atencion, hablar con gente que trabaje en esos roles o hacer carrera como ingeniero desde un rol raso), y despacharlo gentilmente hacia otras secciones de amazon.

todo programador creativo tiene una placard lleno de prototype corpses.

agregar HUMOR, acá y allá.

dedicar capitulos a distintas personas

code quality, la petit engineering vs. la big one, big engineers are blind to crappy software as long as it merrily works. the barn and the cake: getting depleted and disenchanted from your turned too big to tame project picking small enough projects preguntas honestas: are you willing to get all the ecosystem and production support needed after prototyping ? do not half ass refactor mixed with feature dev

the crystal castle: perfect prototypes vs. fault tolerant software every programmer wants to engineer and build from scratch its rolls royce engine. keep a cuaderno tracking the work you are doing, what is critical, pending or failing, and doodle designs, future improvements you are unwisely have kraft lust to do.

do not get too much in love with design patterns and big engieering approaches (gazillon interfaces, empty long service calls that do just nothing, intermediate adapters everywhere just in case you want to change from one tech to another (typical persistence, etc.). Ejemplo de java sus niveles de abstraccion para persistencia (charla con adrian)

Memes: Mitos (ej. Not bug, it's a feature)