Software Engineering: From Theory to Practice

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.

Bf9f3f29049791136b9b815f59e1f09c?s=128

Meanbee

April 03, 2013
Tweet

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
  15. None
  16. None
  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
  18. None
  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?