Software Development Methods And Some Other Stuff

The Plan for Today 1.Software Development Processes 2.Professional Development

Software development process…basically how to structure a team to get your large software project built on time.

The Waterfall* Requirements GatheringDesignProgrammingTesting/BugfixingDeployment *this is not a genuine software process 1 month 3 months 1 month

The Waterfall* Requirements GatheringDesignProgrammingTesting/BugfixingDeployment *this is not a genuine software process 1 month 3 months 1 month No feedback in the system.

Example of a development process: Scrum

There is a set of desired features called the “product backlog”. These features generally are thought up by the stakeholders and then developers estimate how much time they think each feature will take to develop.

Every “sprint” (usually about 30 days) the stakeholers select which features will be implemented. On bigger projects other teams might weigh in too. But one way or another, a set of features is chosen that takes 1 sprint worth of developer time (as computed by the developer estimates).

Every day, the developers have a very brief meeting together where they say what they did yesterday and what they’ll do today. They work, and they keep track of which features are finished from this sprint’s backlog.

At the end of the sprint, the developers deliver a new working product to the stakeholders who use it and usually that makes them think of some new features they would like which also go in the backlog. Usually there’s an end of sprint meeting where folks discuss what went well/poorly.

Things to notice about Scrum: 1.It provides regular incremental deliverables 2.It has a system that ensures negotiation between developers and the stakeholders: Developers estimate how long each item in the backlog will take Stakeholders decide which will be put into the sprint backlog 3.There are only 3 official kinds of meetings the whole process: Sprint planning meeting where the sprint backlog is decided (this meeting actually has two parts that I’m not getting into) Daily short meeting Sprint retrospective meeting (this meeting actually has two parts that I’m not getting into) 4.Focused on development

Software Development Processes Agile Methods (the ‘new’ hotness) Designed for small teams Fast turn-around is more important that perfect quality Have a small number of well specified procedures Non-agile Methods (still useful) Accommodate large projects often will many other roles (dedicated tester, maybe different roles for junior and advanced programmers, different types of managers, etc.) Generally have more procedures, sometimes forms Even with this, the goal is still to get development working at high speed

An Example of a More Complex Procedure At the beginning of every month the custom C++ libraries that drive the website framework are refreshed from the latest “good” version in source control, they are pushed to “devo” the test server Over the next two weeks, if you want to get something launched you deploy it to devo. This can be webpage perl code or custom C++ libraries. The webpage stays up for testing but if there’s a bug or two it’s understandable. One week before the end of the month, the QA team does a comprehensive test of devo. If anything is still broken it’s considered “blocking the push” and people get paged. At the end of the week, everything on devo is promoted to “master” a website that is like the real website but not accessible to the external world. TA team does another test, and people get paged if there’s problems. At the end of that testing, master is pushed to “production” the live external website, QA tests one more time and the launch is finished.

Things can get a little complex (and there can be drama) Projects can literally have ~100 developers involved with them, all working on different schedules and having different problems. Managing that is a full time job (often the person who does this called a technical program manager). Remember that it’s your job to solve technical problems, so focus on what it’s going to take to get the problem solved, not your ego It is often easier to solve the problem than to convince the person who’s problem it is to admit that it’s their job to solve the problem

You end up working on the networking framework at a video game company. After 4 months, you launch an improved version of the networking framework to universal acclaim. 2 weeks later, a random developer contacts you. He’s noticed that his part of the game has started to sporadically “pause” every couple seconds for no discernable reason. He insists that the only thing he has changed is using your new framework. No other developers have reported any slowness problems. You can’t think of any plausible reason why your framework would cause sporatic slowdowns like this. He tells you that this pausing behavior is blocking a major launch. He says this at 4:57pm on a Friday with the clear expectation that you will spend your weekend fixing this. What do you do? 1.Cancel your Friday night plans and spend the next 2.5 hours getting your system set up so you can reproduce his problem. THEN you start debugging. 2.Complain to your boss about this crackpot and try and get him to give you permission to ignore this. 3.Agree that you’ll look into this without making any specific time commitment, then head out of the office for the weekend and turn off your cell phone 4.Something else (your suggestions welcome!)

Main Things to Remember About Software Development Methods A good method… 1.Provides incremental deliverables 2.Eases negotiation between stakeholders and developers 3.Allows you to focus on development

The Plan for Today 1.Software Development Processes 2.Professional Development

To Be a Good Software Developer 1.You need to master development tools – The command line – Compilation tools like make – Source control system – Scripting languages (for quick jobs) – Other languages, challenging libraries (to improve your flexibility and give you new ideas) 2.You need to improve your environment by building tools and infrastructure 3.(Optional) A portfolio

To Be a Good Software Developer You need to master development tools – The command line – Compilation tools like make – Source control system – Scripting languages (for quick jobs) – A programmatic editor (e.g. emacs or vi) – Other languages, challenging libraries (to improve your flexibility and give you new ideas)

To Be a Good Software Developer You need to improve your environment by building tools and infrastructure Time spent building tools for yourself and your team pays off the long run (and, incidentally, tends you get you a pretty good reputation)

Reputation & Building a Portfolio Participation in groups like the XXX users group (e.g. python users group) keeps your ideas fresh, provides collaborators for interesting projects, and is a network for getting other jobs (or more good developers on your existing team) Ditto for well-known open source projects When you do something cool, put it out there! Even if it’s not the coolest code in the world, it establishes you a someone who goes above and beyond as a programmer

To Be a Good Software Developer 1.You need to master development tools 2.You need to improve your environment by building tools and infrastructure 3.A portfolio Your company should be interested in helping you do these things.