13-15 Mar 2013 in Warsaw - 3 days of great knowledge and motivation boost.
33rd Degree another time proved it's one of the greatest, if not greatest one conference in Central and Eastern Europe. First time it was held in Warsaw Gromada Hotel and in comparison to previous 2 years it was a good choice. It was held on 3 floors so there was no problem with room and access to toilets or snacks. Although there were about 900 attendees the impression of crowd was not so painful.
Everyday we could choose of 5 different tracks. Here I will summarize talks and workshops I attended.
Day 1
Sven Peters
Sven works at Atlassian and spoke about 7 things that worked in his company to make great (agile) teams. He writes his blog at
http://svenpet.com/
Most companies motivate employees by bonuses and commissions but what do they really motivate to? Usually they motivate to get bonuses and commissions, not to make good work. When companies find good people they put them in cages, they limit their possibilities, e.g. force to working in fixed hours, not buying license for tools. What can we do about it? We can sit and complain, make revolution (which usually finishes bad) or try to do little changes step by step. The last one seems to be better approach. Try to change your environment and let it grow. Here are the tips for you:
1) Flowtime - stay in productivity phase as long as possible, don't allow to interrupt it. In Atlassian they first set up flowtime hours when team locked themselves in a room, turned off phones, mail clients etc. and worked on a task. This habit started to spread over company with time but was not ideal. It happened when contact with team was needed urgently sometimes. To fill this gap the team assigned a first point of contact each time - a person who was not closed with others but served as a help to other teams whenever they needed some help. This was better. Other source of interruption are open working spaces and should be avoided. Surely flowtime has its drawbacks - setting attention on single thing may easily lead you to situation when you loose the focus on right thing and pass to the wrong path loosing plenty of time. It's important not to loose this focus.
2) Feed you brain - conferences, organizing coding sessions after work, trying out new things, learning new languages, all this stimulates brain to work better. You can move a meeting to lunch (
'brown bag' meetings) or meet after work on a beer. That's often much better than official office meetings.
3) Say "well done!" - don't afraid to appreciate small things in your team, e.g. when someone spent 2 extra hours on client's problem appreciate it. Tell him he did a good job (even when mostly he screws things up).
4) Report robots - nothing consumes more time than writing reports which eventually are not read by anyone. Automate things that are repetitive. Collect data and put information radiators all over the office (a TV in kitchen, posters, etc.) This is better than to sit and read reports and you're getting naturally more aware of numbers than studying them. Finally everyone in the office knows the numbers, not only managers. People are more aware of what's the actual outcome of their actions.
5) Eat your worn dog food - when you build a product try it yourself before releasing to users. Give it to your co-workers for alpha testing. It hurts sometimes when your colleague from opposite desk complains about it but it's the fastest feedback ever. Think like a customer, understand customer better.
6) Do a special day - leave your current items for one day, pick up things that stack deep in your backlog and tidy them.
7) Experimentation time - check your cool ideas, build a prototype. In Atlassian they have 20% time for building project of the ideas, that can help company to improve product. It's called "innovation week". This starts usually after a milestone release when there's more time and none will be interrupted by current sprint. It starts with a meeting when team gathers all ideas. They make a plan, maybe a mockup and next day they sit 24h building the product. Day after they present the product to other people in company ("ship it day").
Dan North
Dan spoke about daily-life decisions:
* builds: automated or manual
* testing: automated or manual, or test after, or test whenever
* architecture: synchronous or asynch.
* architecture: monolithic or small components
* programming: object-oriented or functional
* threads or single-event loops, or actors, or CSP (
Communicating Sequential Processes)
Each decision is a trade-of. When we build solution the need should drive the solution, e.g. when hacking to find out proper architecture of many possibilities often writing code first sounds better than TDD when after all we don't know where we're going to, deleting code often but if TDD is quicker for you in such cases then use it. Do with what you're more familiar and leads you toward solution quicker. Premature optimisation is a source of all evil. Try hybrid solutions. Use Spike and Stabilise pattern - create product that works, ship it as quick as possible to get user feedback and then when the solution starts to form try stabilising it, cleanup some code, add more tests.
Decision whether use objects or functions is pointless, why not trying both depending on purpose? Same goes for builds. In some cases manual builds sound better choice - you pay attention to details which can be forgotten during automation. When product evolves so should your methodology. When automatic build took, say 3 minutes and you added new features it will slow down. You should tweak build process to enhance performance rather than allow it to live its own life - automation is misleading sometimes.
Automated testing is OK when e.g. testing repetitive set of data, but manual testing give other view, e.g. when clicking over UI you get understanding of user experience, you spot each change to the application when new features are added, how it impacts end user.
Short Software Half Life pattern - how long will I wait until half of my code will not be anymore there. It's good to divide software to small cohesive components, each of which does one thing (this is how Linux was designed). Each component has soft center and hard shell, means clearly defined interface with other components. It's then easier to throw out such component, rewrite from scratch than if whole system is monolithic - there's term called micro software architecture.
Evaluable architecture is one that's changing over time to adapt to user needs. Evaluable e.g. has nothing to do with DRY (Don't Repeat Yourself) principle of programming - analogically to DNA which takes main part in evolution: DNA does not refactor, it copies. Same for software - it's easier to remove part of a system if it's not coupled with other parts (this breaks DRY rule).
The conclusion of speech is that only when you know what you're trading off you can make informative decisions.
Ted Neward
More about Ted is on his page
www.tedneward.com
India produces 350 000 engineers every year. Along with India more eastern countries like Poland, Romania ships cheap engineers on market. At the same time automation is happening, machines take over jobs which not long ago were done by people. Can we avoid it? How can we protect our job?
We can't. We can evolve. Something that machine can't replace is creativity.
Nothing can replace people like those who invented
Evernote or
Dropbox.
These people are
iconoclasts. They are people who beat
'status quo' for sth better for the World.
They are people who are brave enough to be driven by logical thinking, not group thinking.
Group thinking is dangerous. We are biologically wired to follow the herd. This is sth we should avoid.
Iconoclasts like everyone fear to step out of crowd, but they refuse that fear to influence logical decisions.
"Failure is only the opportunity to more intelligently begin again" - said Henry Ford.
Some iconoclasts finished dead when trying to force their ideas, some where more successful. The difference between them is that ones could convince people while other barely tried.
The social intelligence is sth that forms of how we perceive familiarity and feel reputation. This is how we should convince people to new ideas. We should step by step make them familiar with it and build our reputation. None believes someone unknown who at first glance talks bullshit according to what's commonly thought by group.
Erik Dörnenburg
Erik spoke about quantifying the quality and presenting on charts.
The clue is to aggregate some information but throw away other, use graphic views and take data at right level. There are different metrics to be used:
- lines of code
- method length
- class size
- cyclomatic complexity (the number of nested loops)
- coupling between classes
- weighted methods per class
Eric shown several diagrams and pointed out tools that we can use to generate them:
InfoVis,
Gephi,
SourceMonitor,
CheckStyle,
iPlasma.
The same talk can be viewed
here.
Tugdual Grall
Tug runs blog at
http://tugdualgrall.blogspot.com/.
Rational databases scale bad and it's expensive (Oracle RAC). NoSQL comes to rescue.
Couchbase is one of document databases. Entries are stored in JSON format. Architecture is as below:
Couchbase server runs on C++ and V8 JavaScript engine. Cluster manager runs on Erlang.
In comparison to MongoDB it has worse query language but better scalability. Usually the project lifecycle starts with Mongo and if it's enough then it stays on Mongo but if it needs more scalability, better performance it moves to Couchbase.
Search mechanism in Couchbase can be enhanced by adding
ElasticSearch component.
Couchbase team is also working currently to release Spring Data package.
Day 2
Tugdual Grall
Good hands-on training of Couchbase. I've put materials at
github. Especially useful is example of
simple web app demonstrating all Couchbase operations.
Erik Dörnenburg
Eric gave 2 metaphors of software development:
1. Building houses. House architects need to deal with complex planning of every detail of the building before development has really started. Build phase is short in comparison to usage phase. Good idea at the time of development does not necessarily have to be as good after several years of usage. Refactoring the city is hard and requires good and detailed plan. This metaphor is not that close to software development where build phase and usage phase are mixed. We don't build software once and use it but constantly refactor and adapt to evolving requirements. More close to software development is 2nd methaphore
2. Gardening. Although more accurate, we prefer to call ourselves developers than gardeners. We wouldn't put gardener on our business card as it appeals to us with less social respect. However gardening is much like software development, it requires from gardener to constantly work on keeping the garden in right shape when time and surrounding conditions change (e.g. different seasons of year, changing climate, ageing of plants).
Software development has more to do with evolution which consists of:
- recombination
- mutation
- fitness function
The same happens in IT in Open Source and technical startups. This is not that architects can plan at the beginning and only once how product will look like. Many frameworks emerge but only a few become successful. Fitness function depends on number of people who use the framework.
Abstractions in software development are useful but you need to know the details underneath, e.g.:
Web application can get from server JSON containing url links to more details which can be navigated on demand. Same concept on mobile application won't work because limited bandwidths. Fetching details from links would be too slow. Other example is messaging abstraction. Let's have a method:
sendMessage(String topic, Message message) which nicely encapsulates whole stack of invocations from top to the bottom where network packets are sent. This abstraction works as long as you remember of max. size of message to send with MTU token of 15000 bytes. Otherwise the method gracefully fails, because the abstraction hides that detail. Here we come to term of 'mechanical sympathy' this is where software and hardware should work in harmony.
Reasonable architecture starts with simple concept and evolves when needed. It' said the architecture should be componential, but not necessarily at the beginning. The same as monolithic architecture can evolve to componential, the same a componential can evolve to turn multiple components into one, which is presented on pic below:
The conclusion is that architecture and development cannot be separated (as e.g. in civil engineering).
We cannot do architecture upfront but it has to be validated by code. Most of the things that traditionally architects did (diagrams, design, documentation) should be done by developers, by tools or not done at all.
The tips & tricks given by him are:
* users expect same performance on mobile as on desktop or even better
* 10 sec. maximum waiting time on desktop application but 3 sec. on mobile
* mobile Safari browser has only 25KB JavaScript cache, so do not use same JavaScript frameworks for mobile pages, e.g. instead of jQuery use z
epto,
xui,
microjs
* use little CSS, JavaScript because it takes time to parse it (100ms/1KB), minify it (gzip)
* reduce DNS lookup on page, e.g. limit redirection (from mypage.com to www.mypage.com)
* load first necessary content and then the rest (adverts, statistics JS)
* do not use background image, use CSS gradients instead
* instead using images use icon fonts (free icon fonts
here), they scale nice and take little size
* instead of shifting images on page use CSS3 animation.
* click event takes about 300ms for operating system to recognize, it is delayed depending on screen resistance, dust, etc. so instead on-click event use touch-start events and touch-end events.
* use websockets for persistence pipe with server instead of http
Simon is Tech. Evangelist at Oracle Corp.
He's done intro on
Raspberry Pi platform - an ARM processor based board.
Project emerged from
BBC Micro project started in 1981, which was to serve British college students with platform for learning computer science. In Feb 2012 first Raspberry Pi was released.
It contains:
- ARM 11 core 700Mhz processor overclocked up to 1GHz
- 256MB (release 1) or 512MB (release 2) RAM
- HDMI & composite video so can be connected directly to monitor
- 2x USB
- audio out
- Ethernet (release 2)
- header pins
Simon demonstrated some real-life applications like:
- LegoMindstorm motor steered with brain waves
- mechanic arm steered with joystick
- voice synthesizer
Really full of fun presentation.
She also gave some tips how to start freelancing there:
- specialize in what you do, do it very well
- create outstanding profile, add portfolio
- search only jobs that fits exactly your skills
Setting up freelancing business takes time and effort but is becoming more popular. It gives several advantages one of which is flexibility, but this is not a work for everyone.
After becoming recognized by clients freelancer can move to entrepreneur role, hiring people to accomplish his projects.
Day 3
Workshop led by Hakan Gurel - Amazon Solution Architect (hakan (at) amazon.lu) and Krzysztof Marciniec - Technical Sales Representative (marcinie (at) amazon.lu)
I have never used
AWS before. This gave me a huge dose of new knowledge in reasonably short time, rather than spending hours on digging through Amazon jungle of documentation.
We succeeded setting up a Linux node with Python-based web application, configured db storage for it and set up load balancer in front of. The app front is simple - a photoblog, check it out at
http://ec2-23-20-243-172.compute-1.amazonaws.com/. We got also one more course in pdf showing how to use AWS transcoding. I placed all materials at
github.
Venkat on example of world great empires in history gave a few tips for developers:
* Leverage the power of democracy
Good leaders are those who create things and give it to people watching what they'll do with it, helping when they need it. In analogy to it Java is a dictator. It's enough to watch at exception handling mechanism which not like in dynamic languages when it's left to developer to decide wheather to catch it or not but forced by checked exceptions. Here Venkat recommends a book:
The Wisdom of Crowds by James Surowiecki.
* Be adaptive
To fear of change leads to language stagnation
* Complecency and arrogance kills
As an example Venkat gave the time of Inks and Spanish conquistadors. Arrogant tribe emperor underestimated the little amount of Spanish soldiers, well armed in rifles and on horses, in comparison to greatly larger amount of his warriors but armed with spears that led his civilisation to death.
Same in software, new powerful languages emerge. Arrogance leads to bad decisions. Language wars are pointless.
* Revolutionize, not resist.
Hadi works on JetBrains, is a Developer and Technical Evangelist.
He spoke about different software development methodologies, how they try to be cure for everlasting problems like: scoping requirements, planning sprints, dealing with bugs.
NOOO (not only object oriented development)
Having all that rumour we're often loosing focus on the right thing.
All about it is that not learning new methodologies and technologies or languages really matter but helping people. Innovation is about helping people, making their life easier. The talk is also on
vimeo
The hackaton was held along all 3 days of conference in the evenings. Actually it already started the evening before conference. During that time guys created a nice working thing that we can all watch
here and check code at github:
