Software Engineering: From Theory to Practice

This presentation was given in 2013 to first year Computer Scientists at the University of Bath. The aim was to supplement the theory of what students were learning on their software engineering module with that of our experience at Meanbee after a couple of years in the 'real world'.

Presented by Tom Robertshaw and Nick Jones.

Transcript

1. Software Engineering: Moving from Theory to Practice Tom Robertshaw Nick Jones
2. • Graduated in 2011 with 1st Class Honours • Met each other at University • Ran our business while studying • Moved into our office 5 days after last exam Who are we?
3. Project Management
4. Meanbee Workflow
5. Waterfall Vs Agile • Most businesses familiar with Waterfall • Agile tends to produce better products but more expensive • Progress updates easier with Agile • Waterfall easier to plan for
6. Proposal Stage • Usually after the first meeting • Put our thoughts and ideas down on paper • Tap into prospect's domain knowledge • Try and improve on prospect's ideas • Stick a price on it
7. Requirements Gathering • Decide on what we're going to do • Write everything down ◦ Manage client expectations ◦ Ensure you're speaking the same language • Write a good requirement • Collaborate with client
8. Task Management
9. Task Management • Gantt Chart • To-do list apps • Studio Meetings • Instant Messaging • Codebase
10. Task Management • Tasks are exploratory, you'll need to adapt • Make a management style decision • Track time for tasks
11. Team Development
12. You can't do everything • As much as you'd like to, it's impossible • You're more efficient doing something you're good at • Other people have good ideas • Extrovert != Innovation
13. Our Departments • Frontend ◦ Visual Interaction and User Experience ◦ HTML, CSS, JS, template level PHP • Backend ◦ System Architecting and Service Implementation ◦ PHP, SQL, JS • Backend needs to support Frontend
14. Version Control • Developers "check-in" sections of code along with a message • Traceable and accountable • We use git, created by Linus Torvalds
17. Code Reviews • At least one other person should see something that you've written • Four-eyes principle • Improves the quality of the code • Improves the developer's skills
19. Develop Features on Branches • Keep the development branch stable-ish • Experiment on a different branch • Merge in once complete
20. Debugging and Testing
21. Static Analysis • Mess Detection ◦ Cyclomatic Complexity • Enforce Coding Standards ◦ Naming conventions ◦ Tabs vs Spaces
22. Unit Testing • Test portions of code • Enforces good code structure • Upfront time investment but avoids expensive regressions • Useful code coverage metric
23. Functional Testing • Run automated tests with interface • Saves developers testing frontend upon each change
24. Continuous Integration • Run your tests every time a developer checks in code • Find regressions • Find errors quickly
25. Continuous Integration
26. Software Reuse
27. Software Reuse • Knowledge is cumulative, why not software • Increases efficiency & profitability • Provide greater value to future clients • Sell your by-products • Needs to be organised
28. Re-use ready code • Modular code • Loosely coupled • Extensible • Tests • Useful documentation
29. getcode.io
30. getcode.io
31. Client Communication
32. Your point of contact • You're landed if your stakeholder is technical • Keep them up to date • Manage expectations even/especially when behind • Agile projects are better for progress updates
33. Use a traceable medium • Avoid the telephone • Email is old fashioned, but incredibly useful • Project Management tool is best for actionable tasks • Keep a balance between accessibility and productivity
34. Client Documentation • Feature-rich system but is is usable? • Developers like to make their lives easy • Document how a client should use the system ◦ Careful of language ◦ Screenshots • Build it so that they won't need it
35. Five years on... • Build it well, but build it right • Time efficiency is money • Get used to group work • Management can make/break project • Deadline's flexible, product isn't
36. We're done. Any questions?