Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
What Makes a Good Development Process?
Bruce Eckelon 22 April 2014
Transcript of What Makes a Good Development Process?
Wrote "Thinking in C++," "Thinking in Java"
Latest: Atomic Scala
Currently calling myself an "Organizational Philosopher" (which excuses me from accomplishing anything) focusing on self-organizing structures.
Bruce Eckel www.Mindviewinc.com
A review and high-level observation of ideas and practices the development community has evolved over the last 20 years.
Help fill gaps in your knowledge, but perhaps also reveal patterns of the problems we’ve been solving, which might lead us to additional insights.
How are we creating better communication paths with our stakeholders?
How does our new understanding of development influence our organizational structures (à la www.Reinventing-Business.com)?
If you don't have these, you can't do much else.
This assumes that you’re doing production rather than experimental programming. These are basically agile concepts.
These might improve your development process.
These days, it’s Distributed Version Control Systems (DVCS).
If you haven’t chosen one already, try Github -- they seem to be moving forward the fastest.
Or BitBucket, or host your own Git server.
Communication, Honesty, Transparency
If everyone knows what’s going on, they can make better decisions.
Keep the essentials on a public board.
Use a daily stand-up meeting so everyone can check in with what’s going on for them.
Consistent Code Formatting
Despite past arguments and programmers staunchly wanting to format their own way, a number of languages have begun standardizing code formatting styles.
Go, for example, comes with the built-in
If you have to mentally re-parse everyone’s code formatting style when you read it, you waste brain cycles that are better used for understanding the actual code.
In programming, every compromise adds cognitive load
This is NOT a consensus decision.
Building by hand is tedious and mistake-ridden.
Pressing “go” remembers to do all the things, every time.
People keep re-inventing these.
The best ones seem to be based on existing programming languages: Gradle & Rake, for example.
Testing and the release process should also be automated.
Automated test frameworks make sure that things are actually working, and ensure that new code doesn’t introduce errors in existing code.
Acceptance testing creates executable agreements about what a product will do.
Test as much as you can, all the time.
But write tests with value; don’t create a culture where people write tests just to produce arbitrary “test coverage.”
How do you find out what the customer really wants?
Small, working features created sooner deliver value faster
The customer wants value.
The sooner they see it the sooner they can course-correct.
Deliver higher-value features first.
Create a MVP and incrementally add complete features
Even if the Minimum Viable Product (MVP) does nothing but (for example) provide a working login, it takes you through the whole cycle and gives the customer a better idea of how development works.
Consider continuous delivery.
Short, Timeboxed Iterations
A deadline determines both time and features (and is never realistic).
A timebox only sets the time and lets the feature set adapt.
Completing steps and features on a regular basis makes everyone -- developers and customers alike -- feel good because they’ve got something real they can get their hands on.
If things are going wrong, this reveals it sooner.
Always Be Planning
Have public lists to capture new ideas, new feature requests, and new problems any time they show up.
Re-prioritizing can happen at any time.
When it’s time for a new iteration, just take the top of the list.
Capture Obstacles and Risks
Keep a public list of things that are potential: if you run into an obstacle once but are able to overcome it, or if you see some risk that isn’t present now but might cause trouble later.
Our tendency is to ignore these and pretend they won’t happen, but if we are keep them in mind then we have a chance to fix issues or head off risks before they have a chance to do damage.
An excellent book on risk analysis is DeMarco & Lister’s “Waltzing with Bears.”
Trying to predict well enough to set deadlines is fruitless.
Instead, measure actual progress in order to get an idea of how things are going.
Use measurement rather than wishful thinking, and perhaps you can find better ways to remove productivity roadblocks.
Your actual velocity + your feature set tells your current finish date (via the “burn-down chart”).
You’ve got to be able to keep doing it.
If your process relies on overtime or a “go faster” button, it’s not sustainable -- you'll get burnout.
Learn From Mistakes, and Adapt
Before bolting forward, have a retrospective on what you just did.
What worked, what didn’t work?
Use this to tune the process itself and you can be even more productive.
A Process for Changing the Process
Address tensions. Don't let them become "just the way things work around here."
Use “Brain Writing” (not storming, and “no guessing or confessing”) so everyone is heard.
Capture process improvement ideas with the bug tracking system.
Get Rid of the Bad
Bad things have 5x the negative impact vs. adding good things.
Different Kinds of Testing
One rabbit hole you can fall down is writing code in a more complicated way “because it will be faster.”
The use of a profiler will settle the arguments -- whether that code is actually faster, and more importantly, whether it matters.
More understandable and maintainable code is the best choice in almost all cases.
How do you debug?
How can you do it in such a way that if the bug shows up again you don’t have to rebuild your debug scaffolding?
Can you write tests that encode the debugging, that prove why you wrote the code in a particular way, and that will catch new bugs?
How do you bring new people up to speed? ("Onboard").
How do you keep everyone from getting stuck using the same thought processes?
How do you discover new ways of using languages, tools and libraries?
Do you go to conferences, and if so are they the best ones for your needs?
If learning isn’t built into your development process, how can it happen?
Don’t Manage, Facilitate
Buy-in is important.
When you “manage,” you’re doing command-and-control.
When you facilitate, you’re helping and enabling.
A useful tool to help at times to work on specific issues, but probably not all the time. For example:
Pairing as coaching, or onboarding new programmers
Pair debugging if you get stuck
Easier to find developers
A different way of working, with its own challenges
Remote workers must have first-class status
Everyone agrees this is the best way to find errors and transfer knowledge, but hardly anyone does it.
Google does code reviews by another programmer as part of the checkin process, but not group reviews (admittedly these require trust building, but the results can be very powerful).
Gerrit provides web-based code review for git-based projects.
Select sections of code for group discussion.
Treat code reviews as learning opportunities. Shaming doesn’t help.
TDD helps in numerous ways by changing your code to work better for testing, and focusing on functionality first.
TDD seems especially useful when creating unit tests, which have a small surface area and help ensure that a bug doesn’t happen in a unit of code, and that you can rapidly find the problem when it does.
But there are also situations (e.g.: rapid experimentation, developing algorithms) where it doesn’t seem appropriate.
Acceptance testing from story requirements produces targets that both you and the customer understand.
RSPEC and similar approaches allow acceptance tests to be created more automatically and produce more readable results.