"Why they're called a 'buddy', I don't know. It's kind of like calling my IRS auditor my 'buddy'."
(Non securitur: "If you give me the right hardware, I can probably get Excel to bring me more iced tea.")
[The immediate problem I'm seeing with this (presumably canonical) SDL model is that waterfall doesn't work for security, because there are always new threats, so, e.g., the threat model is out of date before it's even been written. "Final security review" especially doesn't seem meaningful. I might be jumping ahead as far as this process really needing to be agile instead.]
"How many of you wait until the end to get performance right? Do you do a 'performance push'?"
Agile! Here we go!
How do we get the same gains with a less-heavy process and less up-front design?
Security is just as much a part of every developer's job as, e.g., reliability
Appoint a Security Owner, preferably one who cares whether the app is secure or not, whose responsibility it will be to ensure that the team meets security goals day-to-day
Need to train every developer to know what a security bug looks like
Agile Threat Modeling
Lightweight, rapid
Sketch DFD on whiteboard
Include threat mitigations in the feature backlog
Does management want to learn how insecure your app is from you... or from a hacker?
Use code-scanning tools daily or weekly
Peer code review; anything that increases quality, increases security
Check for banned APIs at code check-in time?
Crypto: don't try this at home. Hire a pro to review.
Unit-level, object-level security testing; write at same time as functional tests
"Throw some evil inputs at it" when running tests
Security Push is good to get everybody's head in the game, and/or for legacy cleanup, but all the rest of the time security needs to be every day, every sprint, whatever
We could make Agile the more secure development approach... it lends itself, we just don't capitalize (yet)
Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts
Tuesday, November 06, 2007
Agile 2008 (p&p, day 2)
Agile 2008 conference seems like something we should get into.
Particularly, we might have interesting things to say about organizational culture...
Particularly, we might have interesting things to say about organizational culture...
Post-agilism (p&p, day 2)
The Agile forest for the Agile trees: too much attention to individual practices than understanding the broad principles; form over substance
Sounds like the difference between "Agile Tragedy" and "Agile Comedy" is communication, practically an encounter session. Telling truths, even when difficult. Bi-directional.
Aha: Agile is about trust, building it, maintaining it, specifically earning it.
Zen agile, neo-agile, postagile... can jettison all 12+ practices and still be little-a agile
Shared understanding of what "done-done" looks like
Empowered, own the problem, it is the team's to suck or shine
Incremental understanding; learn as you go about all aspects of what's going on (including each other, the business area, the customer, etc.)... must accept that you don't know up-front... must seek to learn continuously
Warning signs
"Let's say you have an agile team, and you have team members who don't want to be agile. You can't fire them, and you can't promote them. Where can you put them to minimize the damage?" (Ted rules!) It's better to bring them into the team, but if you can't, then you've either got to figure out how to be a team without them, or just don't do the hyper-team thing at all, which is a valid option.
Peter Provost rules!
Sounds like the difference between "Agile Tragedy" and "Agile Comedy" is communication, practically an encounter session. Telling truths, even when difficult. Bi-directional.
Aha: Agile is about trust, building it, maintaining it, specifically earning it.
Zen agile, neo-agile, postagile... can jettison all 12+ practices and still be little-a agile
Shared understanding of what "done-done" looks like
Empowered, own the problem, it is the team's to suck or shine
Incremental understanding; learn as you go about all aspects of what's going on (including each other, the business area, the customer, etc.)... must accept that you don't know up-front... must seek to learn continuously
Warning signs
- Silent team room
- Afraid to change existing code
- Customer unavailable
- Don't ship frequently
- Talk talk talk (yay!!)
- Ask how we'll solve the problem(s) together
- Guide, don't bully (oops)
- Gotta listen, too (hmm)
"Let's say you have an agile team, and you have team members who don't want to be agile. You can't fire them, and you can't promote them. Where can you put them to minimize the damage?" (Ted rules!) It's better to bring them into the team, but if you can't, then you've either got to figure out how to be a team without them, or just don't do the hyper-team thing at all, which is a valid option.
Peter Provost rules!
OMG Steve McConnell (p&p, day 2)
Basic motivations for agile:
Developers: want less overhead, want to focus on "real" work
Customers: want flexibility
Value delivery keeps up with cost
"Especially useful when schedule and resources are fixed, and mission is to provide maximum business value within those constraints"
Agile Manifesto (ca. 2001)
"Reduced emphasis on long-range predictability of features--especially of the combination of cost, schedule and features"
Variation of methodologies is really about the balance of up-front work vs. in-iteration
In-phase defect removal goal is always 100%, at least in theory
Aha: in addition to code defects, can also find requirements defects, architecture/design defects... leaving major testing to end allows build-up of latent defects (all kinds), unexpected fix time
("Evolutionary Delivery" illustrated with arbitrary 25% balance, looks good for us)
Packaged methodologies
XP: developer focused; abandoned more often than retained
Scrum: workflow/management focused; retained more often than abandoned
Few projects use all the practices of a given method; claim of "synergy" among practices is invalid
Useful practices
Overhyped, buzzwordy, has led to cynicism
Not the best solution for every company, just for many; there are still cases where sequential dev is the best fit
Best outcomes
Importance of short, iterative and/or incremental cycles
Die Waterfall die!
Check-and-balance against overly bureaucratic CMM
Reality check against "omniscience" of requirements, planning, design
In conclusion:
Steve McConnell is a great communicator. I feel like this stuff is really accessible to folks at all tech levels, which makes it helpful for me in taking the Gospel back to our stakeholders.
Developers: want less overhead, want to focus on "real" work
Customers: want flexibility
Value delivery keeps up with cost
"Especially useful when schedule and resources are fixed, and mission is to provide maximum business value within those constraints"
Agile Manifesto (ca. 2001)
"Reduced emphasis on long-range predictability of features--especially of the combination of cost, schedule and features"
Variation of methodologies is really about the balance of up-front work vs. in-iteration
In-phase defect removal goal is always 100%, at least in theory
Aha: in addition to code defects, can also find requirements defects, architecture/design defects... leaving major testing to end allows build-up of latent defects (all kinds), unexpected fix time
("Evolutionary Delivery" illustrated with arbitrary 25% balance, looks good for us)
Packaged methodologies
XP: developer focused; abandoned more often than retained
Scrum: workflow/management focused; retained more often than abandoned
Few projects use all the practices of a given method; claim of "synergy" among practices is invalid
Useful practices
- Short release cycles (1-4 weeks): does not have to be externally to the customer; virtually always valuable
- Rolling-wave planning: long-term (2-12 months); detailed (30-60 days)
- Timebox development: commit to delivering fixed set of functionality in given timeframe; high morale, visible progress; need a rest period or different activity between sprints
- Empowered, small, cross-functional teams: include all stakeholders needed to make binding decisions
- Active management (coach, Scrum Master): "Theory Y" style; remove barriers to good work
- Coding standards
- Frequent integration & test: daily build and smoke test (no point building if don't also test that build is OK); note that you don't have to deliver new functionality every day, nor even check code in every day
- Automated regression test (TDD): virtually always a good practice with new development, problematic for existing/legacy systems
- Postmortem for each release
- Customer-provided acceptance tests: ongoing participation hard to sustain; customer testers don't always know meaningful comprehensive tests
- Daily stand-up meetings: a good idea that can go too far; less often, shorter, can be OK
- Simple design: don't oversimplify; must fully satisfy known requirements
- Test-first development: culture shift is difficult, high discipline required, worth the effort
- 40-hour work week: we really mean a sustainable pace of work
- System metaphor
- Onsite customer
- Collective code ownership
- Pair programming: good if used selectively
- Refactoring: prone to abuse
Overhyped, buzzwordy, has led to cynicism
Not the best solution for every company, just for many; there are still cases where sequential dev is the best fit
Best outcomes
Importance of short, iterative and/or incremental cycles
Die Waterfall die!
Check-and-balance against overly bureaucratic CMM
Reality check against "omniscience" of requirements, planning, design
In conclusion:
Steve McConnell is a great communicator. I feel like this stuff is really accessible to folks at all tech levels, which makes it helpful for me in taking the Gospel back to our stakeholders.
Monday, November 05, 2007
p&p Parking Lot
Day 1: Architecture
Enterprise Service Bus: complicated. I couldn't figure out how it'd be useful for us.
Scalability: seemed really geared toward high-availability, high-traffic apps, which mine definitely isn't. The advice about degrading services gracefully is helpful, though.
SecPAL: new standard is an oxymoron, it's all game theory figuring out who's going to adopt it and how many peers would need to in order to make it useful.
Day 2: Agile
Does the fact that day 1 was "architecture" make this a "waterfall" conference?
Empirical research on Agile adoption: zzz... I mean, it is awesome, I'll take the deck to work for show-and-tell, seriously. Why's it called a "deck", anyway?
Longitudinal study shows correlation between introduction/adoption of Scrum (specifically) and less overtime (fewer hours and less often). This makes agility interesting for us because the sustainable pace is less negotiable in our environment, while productivity is what flexes...!
Day 3: Development
Totally unable to overcome skepticism of IronRuby. Also, speaker less than riveting. He's talking about IronRuby while presenting on a MacBook. Bwah?
Rocky: "Sharepoint is the new Access!" LOL.
Models: zzz. I suck for not paying attention to this.
Day 4: Software Factories
Microsoft's ill-fitting latte lids, thoughtfully supporting me in my mission to spill coffee on important technology persons. Starting, today, with myself.
In the half hour before the keynote, Scott H popped up a Notepad window over his lead slide, and hacked out a short story about someone at the conference this week actually playing Quake and CounterStrike during the sessions, headphones and all, and finished with the question: how many of you are planning to play CounterStrike during my keynote? About five minutes before his talk began, he ^A-deleted it. Never said a word about it. It was like an Easter egg for presentations.
The entire rest of day 4, so far: my brain hurts. My laptop's brain hurts. My chair's brain hurts.
Swag update: Code Complete 2, Test-Driven Development in Microsoft .NET
Enterprise Service Bus: complicated. I couldn't figure out how it'd be useful for us.
Scalability: seemed really geared toward high-availability, high-traffic apps, which mine definitely isn't. The advice about degrading services gracefully is helpful, though.
SecPAL: new standard is an oxymoron, it's all game theory figuring out who's going to adopt it and how many peers would need to in order to make it useful.
Day 2: Agile
Does the fact that day 1 was "architecture" make this a "waterfall" conference?
Empirical research on Agile adoption: zzz... I mean, it is awesome, I'll take the deck to work for show-and-tell, seriously. Why's it called a "deck", anyway?
Longitudinal study shows correlation between introduction/adoption of Scrum (specifically) and less overtime (fewer hours and less often). This makes agility interesting for us because the sustainable pace is less negotiable in our environment, while productivity is what flexes...!
Day 3: Development
Totally unable to overcome skepticism of IronRuby. Also, speaker less than riveting. He's talking about IronRuby while presenting on a MacBook. Bwah?
Rocky: "Sharepoint is the new Access!" LOL.
Models: zzz. I suck for not paying attention to this.
Day 4: Software Factories
Microsoft's ill-fitting latte lids, thoughtfully supporting me in my mission to spill coffee on important technology persons. Starting, today, with myself.
In the half hour before the keynote, Scott H popped up a Notepad window over his lead slide, and hacked out a short story about someone at the conference this week actually playing Quake and CounterStrike during the sessions, headphones and all, and finished with the question: how many of you are planning to play CounterStrike during my keynote? About five minutes before his talk began, he ^A-deleted it. Never said a word about it. It was like an Easter egg for presentations.
The entire rest of day 4, so far: my brain hurts. My laptop's brain hurts. My chair's brain hurts.
Swag update: Code Complete 2, Test-Driven Development in Microsoft .NET
Subscribe to:
Posts (Atom)
