Today we have two professional software developers visiting the school and telling us on state of the industry. This is of course quite limited perspective.
Distinction between skill and experience
Skilled programmers often do the same task in a different way. The only thing that really matters is experience.
Coding Katas
As a professional, you should polish your skills. In our company we do that. Through katas. The developers have an allocated time to gain new skills, refresh existing skills, and learn.
See: codekata.com
TDD
Should we always write tests first? Or be pragmatic and only write tests when you think need them? Yes. To both. We do not always follow strict TDD.
Check the discussion: http://laysnow.co.uk/to-tdd-or-not-to-tdd
On estimations
After the first 6 sprints, the typical overhead of the sprint above the estimate remains on about 50%. Why? Tests and extra quality tools continue to add overheads on top of feature development.
When estimating, state exactly what has been estimated: what is included, and what is not.
Intuition vs. analytical methods: intuition almost always wins. Intuition might be a good proxy to experience.
Transferable between domains? No.
Managers are the worst, and they have the least self insight. (If you got a raise today you really feel you are smarter today than yesterday).
Group estimates show to provide better results.
Bottom line: comparison is the best way of doing estimates. This boils down again to experience.
Maintenance
Software maintenance takes often 70%-80% in the lifetime of the project. Tests can help in long-term, but the cost/benefits ratio is not known.
Structure of teams
Customers more often now come with their own architects, and a set of standardized technologies that are enforced on top of a development team.
Having specialisation roles (like interaction designer, graphic designer, functional architect, requirement architect, etc) complicates the processes, increases the costs and due to market pressures
Product owner should not interfere with the scrum process. “Do not call us, we call you” mantra should be applied to product owner.
Scrum is hard with distributed teams, and changing team members.
We ready to realise almost on continuous basis.
Developers should only have one active task. Focus on one thing at a time.
We use kanban and TDD, but not 100% test-driven.
Code quality
What do we use: Jasmine, JSHint, Karma, JUnit4. Tests are written with the feature in mind, whether the test is unit or integration depends on the feature being tested, and we use pragmatic approach to testing.
Leave a Reply