“ Agile’s early emphasis on self-organizing teams caused some to brand it anarchic. Soothing those fears has led, in too many cases, to team processes that are externally imposed and therefore ossified. To counter that trend, we want to embrace the anarchic strain in Agile. (What should be done to sooth fears, we believe, is nothing more than producing working software at frequent intervals. So long as a team delivers that which satisfies, no one should care if an integral part of their process is capering naked in the light of the full moon.)
AR⊗TA - Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism
Floehopper
thoughts on the bergy bits of life
“ So now we have the worst of both the Agile and plan-driven worlds: the business expects delivery of a fine-grained list of requirements (whether we call it a Product Backlog or a Master Story List), and we have only taken a half-hearted attempt at it compared to the big up-front analysis we used to do. From here on we are on the back foot, constantly negotiating with the business to manage scope, when it’s our own fault they even care about the story-level detail. They see the story backlog and mentally turn it 90 degrees and think of it as a Gantt chart. Happy days!
DanNorth.net » The perils of estimation
“ The probability that you will change a piece of code in the near future increases when you make changes to that code or to code in its vicinity.
Joakim Karlsson › The Locality of Code Changes
“
My last gig I was hired on to be the build guy. On my first day I sat shotgun to their deployment process. The manual process was as follows :-
1. Logon to the ‘build box’
2. Get latest
3. Open visual studio and compile the application
4. FTP the resulting app to a staging area on our production webserver
5. Put the website offline
6. Run any new SQL files against the production database (Hopefully you guessed the execution order correctly)
7. Copy the app into place
8. Put website back online
9. Hope nothing had broken.
“ The researchers are not suggesting fraud, just that the way scientific publishing works makes it more likely that incorrect findings end up in print. They suggest that, as the marginal cost of publishing a lot more material is minimal on the internet, all research that meets a certain quality threshold should be published online. Preference might even be given to studies that show negative results or those with the highest quality of study methods and interpretation, regardless of the results.
Scientific journals: Publish and be wrong | The Economist
“ * Work for the one person who would never discriminate against you. (i.e. go freelance)
* Give in to the dark side and go into management.
* You’ve got a cash cow, milk that sucker! (i.e. be the equivalent of a COBOL programmer) Programmers: Before you turn 40, get a plan B
* Give in to the dark side and go into management.
* You’ve got a cash cow, milk that sucker! (i.e. be the equivalent of a COBOL programmer) Programmers: Before you turn 40, get a plan B
Jay Fields' Thoughts: Developer Testing: Welcome to the Beta Test
Unit testing suggestions :-
- setup methods are evil
- test one thing at a time
- maintainability > no duplication
- test names are comments
- zero or one mock per test
- expect literals
- create test data builders
Integration testing suggestions :-
- a dozen or less tests
- run as part of the build
- use a powerful, high level language
- stub external dependencies
- happy path testing
“ Still there are interaction designers out there that think they can come up with a bunch of user studies, wireframes and flash prototypes and just hand them over. I’d say they have to adapt or start looking for a new career. We really have to work together on this.
Agile interaction design … take 3
“ You’ll know when you’re on to something special, because people will love it so much they’ll tell everyone. If people aren’t telling their friends about it yet, don’t waste time marketing it. Instead, keep improving until they are.
Are fans telling friends? If not, improve, don’t promote.
“ The argument is that if you have poor internal quality — in particular if your “definition of done” is not strong enough and does not require you to keep your code in tip-top condition — then there will be a hidden accumulation of stuff-left-to-do.
The Quality of non-declining Velocity
