Slide 1

Slide 1 text

Software Engineering: Moving from Theory to Practice Tom Robertshaw Nick Jones

Slide 2

Slide 2 text

● 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?

Slide 3

Slide 3 text

Project Management

Slide 4

Slide 4 text

Meanbee Workflow

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Task Management

Slide 9

Slide 9 text

Task Management ● Gantt Chart ● To-do list apps ● Studio Meetings ● Instant Messaging ● Codebase

Slide 10

Slide 10 text

Task Management ● Tasks are exploratory, you'll need to adapt ● Make a management style decision ● Track time for tasks

Slide 11

Slide 11 text

Team Development

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Version Control ● Developers "check-in" sections of code along with a message ● Traceable and accountable ● We use git, created by Linus Torvalds

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

Develop Features on Branches ● Keep the development branch stable-ish ● Experiment on a different branch ● Merge in once complete

Slide 20

Slide 20 text

Debugging and Testing

Slide 21

Slide 21 text

Static Analysis ● Mess Detection ○ Cyclomatic Complexity ● Enforce Coding Standards ○ Naming conventions ○ Tabs vs Spaces

Slide 22

Slide 22 text

Unit Testing ● Test portions of code ● Enforces good code structure ● Upfront time investment but avoids expensive regressions ● Useful code coverage metric

Slide 23

Slide 23 text

Functional Testing ● Run automated tests with interface ● Saves developers testing frontend upon each change

Slide 24

Slide 24 text

Continuous Integration ● Run your tests every time a developer checks in code ● Find regressions ● Find errors quickly

Slide 25

Slide 25 text

Continuous Integration

Slide 26

Slide 26 text

Software Reuse

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Re-use ready code ● Modular code ● Loosely coupled ● Extensible ● Tests ● Useful documentation

Slide 29

Slide 29 text

getcode.io

Slide 30

Slide 30 text

getcode.io

Slide 31

Slide 31 text

Client Communication

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

We're done. Any questions?