Binary crosswords
1 like1,257 views
The document discusses the challenges and complexities of creating a product with an engineering team, emphasizing the importance of understanding technical intricacies and team dynamics. It covers the evolution of technology in software development, tools for efficiency, and the necessity of adapting to changes in the tech landscape. Additionally, it addresses the roles within a tech team, the importance of fostering teamwork, and the significance of having effective processes in place.
Binary crosswords
- 2. • Last time we talked about hiring an engineering team • No we talk about creating a product with this team • I do not pretend to give a top notch description of all technics mentioned here. • In fact this is even be the opposite. This is not at all the purpose of the talk • So again a manager oriented thing :-) We start where we left
- 3. • You have ideas/specs/people (3) • You ask around for all the best tool and technologies…a little bit • You still want to believe technical development is deterministic • You have read a book on how it works • Your planning is so that you will get investor with a SkyRocket stuff in 6 months Ready to make a product?
- 4. “Life is what happens when you’re busy planning other plans”
- 5. So after approximately 6 weeks • You regret to have left your job to start a company • You hesitate at learning all programming languages yourself: “I know it should be done this way” • Process tools have already changed twice • One guy has left, so you hesitate to fire a second one, because 3-2 = 1
- 6. Somewhere this is disturbing • The more you talk to so called “experts”, the more you are confused • You know where you want to go, and what your product should feel like. • Simply you do not know which road to take, where to start fix it, and you need more than an anchor • Time to step back
- 7. So let’s find our way • Apprehend the technical complexity of a product of today • Tune your setup • Consider the constituting blocks, and what neuronal connections should be developed.
- 8. It’s so easy for your kids
- 9. Preamb: again, the following are based on my personal feelings along this path. I do not pretend to write an history book. A little bit of history
- 10. Dawn of personal computing Unix MacintoshZX81 Micro Computing: we write applications to manipulate data and first of all to create documents (text, music, …) and move them to an another support (CD, paper). Content is the output and we forget Unix 1970 1981 1984
- 11. A networks comes in Server comes back : we write content to present it and technology to search it. Clients are strong but start to be seen as way to browse content, in addition to create it. Age of “universal hope” : all Microsoft, all Java, all HTML 1993 1995 1998/91995 Mosaic Windows 95 Altavista Google
- 12. Free of my movements and friends gmail iPhone Mobile development is creating a stronger link client to server. Browsing of document turns to service (API). Social media provides influence of other. Cloud computing bring programmable computing power. Document export is now barely an issue (press online players, Streaming music) 2004 2008 2008 Facebook 2006 AWS creation
- 13. My data, my objects 2009 2010 2013 Big Data (Hadoop) Nest Founded Android market lead Mobile becomes the number one priority. Technologies are created to handle massive data processing, connected object appears. We have gone so far from document creation. All this has become a full graph and power consumption is a concern.
- 15. Complexity
- 16. Complexity
- 17. Complexity
- 18. Complexity
- 19. Paradox • The more complex it is, the easier it looks. Think about how works a human body. Marvelous machine still not imitated • In vast complex system, each small components brings its own world and complexity. A little bit like “all cells contains the DNA” • A saying goes that the problems solvable by kids are the most complex one in computer science Do not mix the small complexity versus the bigger vision one
- 20. Additionnally • Natural movement: when one has understood something, it becomes a reference. But the more you deal with technology, the less you believe in one, and the more you think about the usefulness of all. Techno of today fades out tomorrow • Creativity brings creativity. Why do some people still look for the universal programming language or method or whatever, when the global system is about individuality. Paradox with the natural movement.
- 21. Additionnally (2) • The more you advance in development the more the simplicity of your product will translate into the proper use of complex technology • Said differently : trying to force a complex system to fit into one simple view is like putting a circle in a square shape (of the same surface) If you believe there is one “easy” solution you’re doomed ,After a while it is as much a question of feeling than knowledge
- 22. Set up
- 24. Cards in hand • Humans are your team. You should enthusiast them every day, while driving strongly into one direction • Means are all the technologies available. There are so many and understanding one is already a complex thing • Tools are here to help you accomplish your goal. But they also require a learning curve and will do nothing by themselves Process will transform all those elements in a fluid system
- 26. Humans
- 27. The CTO • A respectable CTO should be a at first a choreographer • A respectable CTO should still code with what he doesn’t know and knows how to debug. • A respectable CTO should always have the question in my mind : “If I was really coming to this team today, how much time would it take for me to get in, and what would I understand in regards to the target goal” Do not believe a CTO is only someone with “more technical knowledge”
- 28. The team • As a macro system/ as a micro system • Macro should always prevail for a product development.Enforcing this will prevent individualism. This is management job • Each ones brings competence and a Dreyfus level model to the macro system. • Creating a grammar for the product in your team is essential In the end, written form will prevail. The one who believes that it is evident because it looks like will lose.
- 29. Process- Engineering Project Manager • EPM is a concept I met in a big company. • Job description is “remove the road blocks” • Takes note, nag people, manage the bug stack, do report. This is a no-bullshit role. • Think about him/her as a second right hand The only process that will work is the one that you work hard enough to transform into an habit. Someone needs to work harder
- 30. Common pitfalls • Complexity is always done in the name of simplicity. • After development freedom comes too much process • “Do it now” works better in 75% of the cases. Otherwise write a bug • Why are people so afraid to throw away things in the name of “in case of”. Throw them • Avoid arguing, enforce rules • A so called expert is having only his own brain
- 31. The advancing guitarist By Mick Goodrick “The best guitar book ever written”” Apply to software development
- 32. The advancing guitarist for product development • Explore the power of limitations • Don’t be too fast: spend time on all what you can get from a detail • If you enter competition keep it for you. Works fine within your team. Being alone when you work, is the case in 90% of the situations • Nothing is ever done. This is not the case in guitar learning, why would you believe it in Software development
- 33. Means
- 34. • The vast fields of available technologies • Stuff of today will be partially obsolete tomorrow. Whatever people pretends. Still fundamentals stay. Each generation makes a problem important • Choice is always a problem. Take the one that corresponds to your company need : recruiting, time to market, cost Means
- 35. Can I develop faster with this one? As a pure personal opinion, and based on my experience, I consider no technologies brings faster development in absolute
- 36. But… • If you get class A developers, it will go faster • Some technology will be faster to reach an intermediate state (e.g do I need a prototype) • Some technologies will get an ecosystem momentum. • There are always cases where a technology will fit your constraints (e.g databases) • You may choose a technology for a part of the way and switch to another. Be contextual.
- 37. Tools
- 38. Rule of thumb • The only good tool is the one you will adopt. No other. You often read “The tool does this”. This is not true: you do this • You need basically Bug system Build/Distribution System Report & Test System
- 39. Bug system Some example I did cross (Radar is missing :-() It has to become the center point. This is the rule to enforce “write a bug”. Defer the philosophical discussion on “is it a bug or a feature” Anyway…it’s a clever todo list…
- 40. Build and Deployment system • Make software available as soon as it is done. Everyone has the right to some regression • Goes with creating different environments: prod, dev. • Ensure the fact that “anyone” can deploy. If mistakes are made this will be a good lesson • May be painful on mobile (provisioning profiles…) • Goes also with a source version control system and with versioning Better more versions, even not finished, than too less
- 41. Test and report system • Testing has a value only if you test something that you believe will not happen • Testing comes through usage. It is understanding how things should work • Automate tests before a big operation : warning this is time consuming • Reporting is way to link to the user: you may need to create it yourself
- 42. Example: mobile client reporting • Create a log system : defines event class , format, storage mechanism. • First have user send it manually through email • Format the email nicely • Make sure it can be activated remotely • Make an API to report it • Have it work when no user is registered Each step will help you understand what you track
- 43. From the start report
- 44. So what? • The tool created here provides a common reference, a common vocabulary and talks to everyone • It is a preamble to real user situation and so is not an “internal use tool only” • It makes the team ask questions about what happens really in regards to what is supposed to happen • It get cold facts Digging into test and usage is about being drastically honest
- 46. Goal of this part • Provides beacon, push all questions around one topic • Give some familiar technology names • Certainly not be exhaustive
- 47. Elements in the complexity Infrastructure Server Mobile Desktop
- 48. Elements in the complexity API Language Misc Storage
- 49. Infrastructure
- 50. • The power engine of your system: compute, storage, network • You’ve heard about cloud: infrastructure becomes programmable and instantly configurable: one more element gets the complexity DNA • Main Providers What are we talking about?
- 51. Many other players around Answer to particular need, with different level of abstractions and easiness of manipulations. Complete ecosystem around
- 52. • Your system will have to be accessed, back-up, monitored, restored (in emergency), started and stopped potentially by many developers, secured, code deployed • Contrary to the belief that it makes infrastructure easier, after a while cloud forces you to understand many concepts of networking • With great power comes great responsibilities (this is a personal advertisement for Nephorider) • The eternal question : it does not work the same on my local machine : Docker! Implications
- 53. Languages
- 55. The short/no discussion version • There is assembly • There is C • There is Lisp • OK… maybe Java
- 56. Maybe it requires more: explore this • Procedural, Object-oriented, functional • Compiled, just in time compilation, interpreted • Statically typed, dynamically typed • On the client, on the server A language provides a way to think about a problem
- 57. Servers
- 58. What server are we talking about? • Web server versus application server • Web server deals with the requests • Application servers do the work • Between them there is something called CGI (roughly).”I pass the work to my neighbor”. When it fails find which one.
- 59. Web servers • The first in line: needs to be fast • Multiple server for fixed constants and fast answer: CDN • Handle protocol. Remember 80 (non secure) and 443 (non secure) : verify you talk to the right guy, speak in coded language. Read hackers book
- 60. Application servers • May or not work in a CGI like setup (PHP) • They bring a methodology to develop application (MVC) • They link endpoints request to objects, concepts and storage
- 61. API
- 62. Scope of word: application programming interface • Exposes a nice learnable and usable model with a set of functions of methods of the concept of your product • Apply also to the libraries and frameworks you are using • Not an HTTP only concern of course!!! • Should never exposes how it is implemented
- 63. Some principles • Make sure it is learnable easily if you want it to be adopted • Make sure it is 200% coherent • Use the HTTP vocabulary available, read about REST concepts • Make it auto describing : no ambiguity when reading…or parsing. Uniquely identify each entity
- 64. Words you may bumped into • Slices (things little by little), fields (get only partial elements in answer) • JSON means nothing • XML neither…
- 65. Storage
- 66. Storage for what? • Organize and keep data “that has a meaning” • Stored data has another form than live one. It may requires extra data to access it fast • Always question of compromises : how much size to store it, how fast can you access it, how fast can you write it • Growth of the system is important (sharding)
- 67. Databases, databases • At first we all wanted to think structurally • SQL is a programming language designed for managing data held in a non relational database manegement system. • We can say this is talking about a model
- 68. The NoSQL movement • Different types all addressing a particular problem in the SQL world or dealing with particular type of data, in some memory configuration • Do not use it only to “do NOSQL”. When you use it , adopt the mindset Document Graph Key-Value Column based (Big data oriented)
- 69. Desktop
- 70. One of the most famous technology trio
- 71. Looks so easy it becomes incredibly complex and powerful • Originally Document based • Separation of content and display • Document became programmable and turned into applications • Integrate in an ecosystem : tags are element of a semantic puzzle (e.g SEO)
- 72. Evolutions • Full feature frameworks (AngularJS, EmberJS…) provides methodology to develop application • Graphics become more elaborate (e.g SVG) • Handle different output device (e.g Bootstrap) this is what is called “responsive” Strangely enough I find it has less profusion of “new” technologies…but this is very personal
- 73. Mobile (native)
- 74. Lanscape
- 75. Send back to the past • Back to some “forgotten” problems • Power consumption, network quality, speed of execution • But way more demanding as “output level” : usability, animation…
- 76. Communication device • Not only as phone • But as a set of sensors for me (e.g GPS…) • 2 paths communications: normal HTTP, Notifications in all ways (APN…)
- 77. Misc
- 78. • Search : use component (ElasticSearch) or Service (Algolia) • Social networks : gives at first a way to identify yourself, but also access to a vast database of data/users (OpenGraph) • Measure your result : Analytics A few more things to thing about
- 79. Thank You!