Thu Feb 02 23:47:23 HKT 2012 From /weblog/software_engineering

lean

“Introduction of Lean Project Management” - http://blog.aaladdin.com/?p=29

Applying Kanban - http://blogs.lessthandot.com[..]s/applying-kanban-to-it-processes-part-2 http://jchyip.blogspot.com[..]-and-kanban-for-it-operation-kanban.html

Deming’s 14 Points, obvious and theoric, but still a good reading - http://leanandkanban.wordpress.com/2011/07/15/demings-14-points/

(google search) (amazon search)

Tue Jan 31 00:14:39 HKT 2012 From /weblog/software_engineering/testing

antipattern

The evil test:

1. Evil tests create a lock on how the code is implemented.
2. Cause duplication.
3. Builds uncertainty on the tests (red is meaningless).
4. Decrease productivity.
5. Discourage change.

http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-test

use thread in junit - http://softwareintegrityblog.com[..]blog/2007/11/05/false-positives-in-junit

Don't try to test everything - http://www.nearinfinity.com[..]ay?entry=unit_testing_avoiding_extremism

Why TDD fail? Because test is too complicate to write - http://agile.dzone.com/news/why-you-fail-tdd ( I agree it a lot )

Hard to test something? Unreadable tests? Slow running tests? It takes too long to write a test? Some solution suggested - http://www.stephenchu.com[..]/last-d-in-tdd-means-more-than-just.html

Comment out test so that the code compile - http://martinfowler.com/bliki/TestCancer.html

A list of TDD antipattern - http://blog.james-carr.org/?p=44 http://www.exubero.com/junit/antipatterns.html

And the long discussion using random in unittest - http://tech.groups.yahoo.com[..]rivendevelopment/message/20458?var=1&l=1
Here is an example of using random in unittest, it actually same for every new instance! - http://www.skizz.biz/archives/000568.html

Test abstraction smells - http://agileinaflash.blogspot.com[..]com/2011/11/test-abstraction-smells.html

(google search) (amazon search)

Thu Jan 26 20:47:20 HKT 2012 From /weblog/software_engineering

practice

Analysis for Continuous Delivery: Five Core Practices

1. Start with a minimum viable product (MVP).
2. Measure the value of your features.
3. Perform just enough analysis up front.
4. Do less.
5. Include feature toggles in your stories.

http://www.informit.com/articles/article.aspx?p=1829417

(google search) (amazon search)

Thu Jan 26 20:43:49 HKT 2012 From /weblog/software_engineering

defect

The way software defects are seen on traditional vs agile projects reveals something about the differences in organizational culture. Given the following causes of defects...

Type 1: Programming error
Type 2: Misunderstood requirement
Type 3: Requirement defined incorrectly
Type 4: Discovered requirement

http://www.davenicolette.net[..]/index.blog/1590120/defects-and-culture/



(google search) (amazon search)

Thu Jan 26 20:42:55 HKT 2012 From /weblog/software_engineering

agile

http://agiletips.blogspot.com[..]2009/12/agile-is-about-deliverables.html <- and waterfall is about filling the process.

beck_keynote_xp2006, about accountable and responsible - http://www.google.com[..]eck_keynote_xp2006.pdf&ie=UTF-8&oe=UTF-8 http://www.carfield.com.hk[..]are+engineering/beck_keynote_xp2006.pdf?

Common issue of adopting Agile development values to the team - http://www.stickyminds.com[..]=12384&ObjectType=ARTCOL&btntopic=artcol

Compare develop software with same function in Agile and waterfall like process, report here - http://chriswoodill.blogspot.com[..]hy-agile-software-projects-are-good.html

What is agile? http://www.google.com[..]g+agile&sourceid=opera&ie=utf-8&oe=utf-8 http://bradapp.blogspot.com[..]06/05/nutshell-definitions-of-agile.html http://bradapp.blogspot.com[..]2007/04/agile-development-distilled.html

May be minimum waste is the goal, agile is just the by-product? http://jchyip.blogspot.com/2007/05/agility-is-not-point.html http://jchyip.blogspot.com[..]ctive-enterprise-architecture-comes.html http://dreamhead.blogbus.com/logs/33816442.html

Commons anti-pattern - http://www.theserverside.com[..]_id=49239&asrc=EM_NLN_3595241&uid=703565 http://www.dalkescientific.com[..]rchive/2009/12/29/problems_with_tdd.html

How yahoo turn to agile - http://www.devagile.com/modules/news/article.php?storyid=244

Triggers for when to use Agile (any one could trigger):

* There's an advantage to get something partial out now rather than everything later
* Not familiar with technology - want to reduce risk
* Want to engage and develop staff
* Competitive pressure for adaptation and faster delivery

http://jchyip.blogspot.com[..]e-thinking-about-agile-vs-waterfall.html

Agile is about a shift in attitude more than process. It requires a shift in focus that is easy to explain, but hard to put in practice. - http://journal.bitshaker.com[..]articles/2008/11/19/a-shift-in-attitude/

Change in process, lead to change in mindset, and view the problem in difference perpective - http://dreamhead.blogbus.com/logs/33068654.html

Discuss about issues of adopting Agile development - http://www.artima.com/forums/flat.jsp?forum=106&thread=246513 http://www.infoq.com/articles/levison-TDD-adoption-strategy

http://www.agileproductdesign.com[..]oduct_owner_and_problem_shaped_hole.html

Agile, is not a choice of good from bad, it is a choice of best from good - http://martinfowler.com/bliki/ComparativeValues.html

12 Principles for Agile Software Development - http://agileinaflash.blogspot.com[..]08/12-principles-for-agile-software.html

http://www.agile-software-development.com[..]ow-agile-are-you-take-this-42-point.html

http://www.infoq.com/news/2009/11/agile-micromanagement

A article show how mirgating to agile from waterfall - http://www.infoq.com/articles/design-for-hybrid-agile-adoption

Top 10 book - http://www.infoq.com/news/2011/08/top-agile-books

Good and bad about agile - http://www.makinggoodsoftware.com[..]/31/agile-the-good-the-bad-and-the-ugly/

(google search) (amazon search)

Mon Jan 16 22:24:33 HKT 2012 From /weblog/software_engineering/team

pair programming

When to pair, when not to - http://www.markhneedham.com[..]ramming-the-disadvantages-of-100-pairing

This is an excellent arguement -

It's only worth pairing on complex code, rote code yields no advantage.

I think there is a point to this - pairing is about improving design and minimizing mistakes. Rote code that's simple to write yields little opportunities for pairing to make a difference.

Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.

http://martinfowler.com/bliki/PairProgrammingMisconceptions.html

Common pitfall of pairing
http://blog.jayfields.com/2007/09/distracted-pair.html
http://blog.jayfields.com/2007/09/uninterested-pair.html
http://blog.jayfields.com/2007/08/spellchecking-pair.html

Look like a good way to start pair programming
http://magpiebrain.com[..]02/13/pairing-pattern-ping-pong-pairing/
http://c2.com/cgi/wiki?PairProgrammingPingPongPattern

Discussing pair programming - http://www.codinghorror.com/blog/archives/000999.html

Experience sharing of working with expert - http://dreamhead.blogbus.com/logs/13258146.html here is the disclaimer of the blog http://dreamhead.blogbus.com/logs/13258146.html

Why pairing - http://www.shlomifish.org[..]n/opinion-on-the-technion/#why_pair_wise

Pair Programming smells
- Unequal access
- Keyboard domination
- Pair marriage
- Worker/Rester
- Second Computer
- "Everyone does their own work"
- 90% of work 90% done
- People who can't stand to program together
- Debates lasting more than 10 minutes without producing new code
-
Pair-programming smalls - http://agileinaflash.blogspot.com[..]com/2009/02/pair-programming-smells.html http://www.javacodegeeks.com[..]ir-programming-disadvantages-of-100.html

http://kfzhang.thoughtworkers.org/2011/04/open-mind-in-pair/

(google search) (amazon search)

Tue Jan 10 23:34:47 HKT 2012 From /weblog/software_engineering/testing

LoadTest

Experience of using load testing tool - http://www.netatlantis.com/?p=3320 , in his opinions, look like http://www.loadui.org/ is the best

(google search) (amazon search)

Mon Jan 09 22:21:39 HKT 2012 From /weblog/software_engineering/team

effecticient

Cool diagram showing what slow us down - http://www.targetprocess.com[..]m/blog/2012/01/faster-faster-faster.html

Usually, not a good idea to grow a team too big too soon - http://martinfowler.com/bliki/PrematureRampUp.html

Taken from Interview of Charles Simonyi ( http://www.shamit.org/charles_simonyi.htm ) , both the interview and the discussion are nice to read: http://discuss.joelonsoftware.com/default.asp?joel.3.341396 , However, I will think if team work effective, 1+1 > 2

What we should really care about is effectiveness and not efficiency. and effectiveness is often inefficient - http://www.markhneedham.com[..]our-obsession-with-efficiency-dan-north/

Handling emergencies or crisis situations
Handling work stress
Solving problems creatively
Dealing with uncertain and unpredictable work situations
Learning work tasks, technologies, and procedures
Demonstrating interpersonal adaptability
Demonstrating cultural adaptability
Demonstrating physical-oriented adaptability
- http://jchyip.blogspot.com[..]2010/12/8-behavioural-dimensions-of.html

(google search) (amazon search)

Wed Dec 21 22:31:10 HKT 2011 From /weblog/software_engineering/team

architects

http://jchyip.blogspot.com[..]2009/03/some-thoughts-on-purpose-of.html

Organize software delivery around outcomes, not roles: continuous delivery and cross-functional teams - http://continuousdelivery.com[..]ware-delivery-around-outcomes-not-roles/

(google search) (amazon search)

Wed Dec 21 22:08:06 HKT 2011 From /weblog/software_engineering/testing

best practices

Testing Patterns - http://c2.com/cgi/wiki?TestingPatterns

Continuously to break thing so that we know our system is solid - http://www.codinghorror.com[..]11/04/working-with-the-chaos-monkey.html

First rule - http://fishbowl.pastiche.org[..]08/10/01/nothing_is_too_trivial_to_test/

Test first/last is not important? Unit test either? What do you think? http://beust.com/weblog/archives/000477.html

* The name of the test should describe the requirement of the code
* There should be at least one test for each requirement of the code. Each possible path through of the code is a different requirement#
* Test the goal of the code, not the implementation

http://xprogramming.com/xpmag/testFirstGuidelines.htm http://www.theserverside.com[..]AppQuality&asrc=EM_NLN_761453&uid=703565 http://www.coopercode.net[..]og/2007/08/how-not-to-run-beta-test.html

The teaser: Fast, Isolated, Repeatable, Self-validating, and Timely. - http://blog.objectmentor.com[..]es/2007/08/02/not-a-task-but-an-approach http://blog.objectmentor.com/articles/2007/08/02/which-came-first

Corner cases - http://testobsessed.com[..]s/2007/02/testheuristicscheatsheetv1.pdf

One of the targets of TDD coding - http://haacked.com[..]e-code-is-about-managing-complexity.aspx

Design for unit test - http://www.theserverside.com[..]es/content/DesigntoUnitTest/article.html

Push and Pull approach -
http://www.richarddurnall.com/?p=10
http://www.richarddurnall.com/?p=15
http://www.richarddurnall.com/?p=31

When not to test - http://www.junitmax.com/blog/?p=187

http://www.infoq.com/news/2009/06/love_agile_testing

Test the story, rather than the implementation - http://www.davesquared.net[..]ving-to-scenario-based-unit-testing.html

Test the configuration - http://searchsoftwarequality.techtarget.com[..]TSS10ctqa&asrc=EM_NLN_8746433&uid=703565

Feel the deep synergy of design and test constraint - http://michaelfeathers.typepad.com[..]athers_blog/2007/09/the-deep-synerg.html

Another set of principles for automated testing - http://a-sisyphean-task.blogspot.com[..]of-principles-for-automated-testing.html

Priority for tester - http://googletesting.blogspot.com[..]t.com/2011/01/new-years-resolutions.html

A lot of links - http://it-techexperts.com/tutorials/tutorials.asp http://testingspot.net/ http://www.exampler.com[..]-links-biased-toward-exploratory-testing

http://www.makinggoodsoftware.com[..]nit-tests-5-principles-for-unit-testing/

(google search) (amazon search)

Tue Nov 15 01:38:22 HKT 2011 From /weblog/software_engineering

process

Complete agile from beginning to the end - http://agilewarrior.wordpress.com[..]com/2010/11/06/the-agile-inception-deck/

The methodalogic, and the development team you pick, affecting the process you have - http://www.leanessays.com[..]1/07/how-cadence-determines-process.html

More process doesn't necessary solve all problems... in fact it may cause more problem - http://architects.dzone.com/news/process-not-working-must-have

http://www.whattofix.com/blog/archives/2006/10/signs_you_have.php

You might not be agile if. . .

1. The “Send/Receive” and “Save As” buttons initiate most team communication.

2. Your whiteboards are mostly white.

3. “Test-driven” still refers to your car.

4. You don’t yet know what PHB stands for. (It's the "pointy haired boss" in the "Dilbert" comic strip.)

5. You know that CPM stands for critical path method of project management, and continue to rely upon it.

6. You spend more time trying to manage project dependencies than remove them.

7. Someone still believes in the “Can’t Chart.” (Oops, that’s the Gantt chart.)

8. Developers only develop, testers only test, and managers just manage.

9. Simplicity is presumed to be simple.

10. A change control board meets . . . ever.

http://www.versionone.net/Resources/AreYouAgile.asp

http://www.jamesshore.com/Blog/Its-the-Software-Stupid.html

(google search) (amazon search)

Sun Nov 13 10:41:47 HKT 2011 From /weblog/software_engineering/team

communication

Discussion toolkit - http://www.stickyminds.com[..]YCOLUMN&ObjectId=12875&objecttype=ARTCOL

Other tips - http://www.infoq.com/articles/satir-communication-model-teams

Appreciation inquiry, a communication tool helping adopting new thing - http://www.threeriversinstitute.org/AppreciatingYourWayToXP.htm

A lot of engineer will silence when under stress, how do you communicate with them that time? Here are some suggestions - http://now.eloqua.com[..]048&elq=1C1DC5420DC8451CB08AEBA44D4F6BC7

There are five dangerous faults, which may effect to a software engineer: http://www.petrikainulainen.net[..]/the-five-faults-of-a-software-engineer/

Benefit of whiteboard over software, communication! - http://www.iamhukai.com/?p=422

How to communicate with difference type of learners
Active versus reflective learners: "Active learners tend to retain and understand information best by doing something active with it--discussing or applying it or explaining it to others. Reflective learners prefer to think about it quietly first."
Sensing versus intuitive learners: "Sensors often like solving problems by well-established methods and dislike complications and surprises; intuitors like innovation and dislike repetition."
Visual versus verbal learners: "Visual learners remember best what they see--pictures, diagrams, flow charts, time lines, films, and demonstrations. Verbal learners get more out of words--written and spoken explanations. Everyone learns more when information is presented both visually and verbally."
Sequential versus global learners: "Sequential learners tend to gain understanding in linear steps, with each step following logically from the previous one. Global learners tend to learn in large jumps, absorbing material almost randomly without seeing connections, and then suddenly 'getting it.'"

http://pagilista.blogspot.com[..]/03/rich-communication-in-real-life.html

How to handle tough discussion - http://www.markhneedham.com[..]iscussing-the-undiscussable-book-review/

Good message structure underlies all forms of effective workplace communication - http://jchyip.blogspot.com[..]ood-message-structure-underlies-all.html

(google search) (amazon search)

Sun Nov 13 02:25:55 HKT 2011 From /weblog/software_engineering/team

Team work

One nice article about teamwork:

Directing (hi directive + lo supportive, for "enthusiastic beginners")
Supporting (hi directive + hi supportive, for "disillusioned learners")
Coaching (lo directive + hi supportive, for "reluctant contributors")
Delegating (lo directive + lo supportive, for "peak performers")

http://www.cmcrossroads.com[..]bbthreads/showflat.php?Cat=&Number=64809

Is it a people problem or process problem - http://blog.nayima.be[..]01/21/people-problem-or-process-problem/

importance of teamwork - http://www.butunclebob.com[..]leS.MichaelFeathers.ProgrammingOnYourOwn

5 Dysfunctions of a Team - http://www.anticlue.net/archives/000279.htm

A Leaner Start: Reducing Team Setup Times - http://www.infoq.com/articles/pat-kua-onboarding-new , I think article "letting-go" is really insightful - http://www.thekua.com[..]007/09/24/onboarding-strategy-letting-go

A good explanation of what is courage, and the result of didn't have courage. It also mention a bit of how to bulit courage within the team, but not much about it - http://www.xprogramming.com/xpmag/NotXP.htm

A potential issue of focus too much on people, rely on few heros - http://jchyip.blogspot.com[..]12/people-over-process-misses-point.html

Our agile process requires people to spend the effort to listen and talk to each other, working closely. You have to be a people person to like it. It doesn't suit sociopaths. Accidently hiring a sociopath is going to make XP impossible. Trust me, I know. To me this is XP's fundamental weakness. http://jchyip.blogspot.com[..]12/extreme-programmings-fundamental.html

What important is team but not idea - http://www.codinghorror.com[..]g/2010/01/cultivate-teams-not-ideas.html

http://www.infoq.com/news/2011/11/enable-high-performance-teams

(google search) (amazon search)

Tue Nov 08 01:50:43 HKT 2011 From /weblog/software_engineering

estimate

Here is one way of how people estimate percent of completion - http://geekswithblogs.net/optikal/archive/2006/12/31/102381.aspx

I believe the general practice in my company is to take your estimate and triple it. Noone EVER complains that a project was completed too quickly. - http://discuss.joelonsoftware.com[..]iscussTopicParent=15151&ixDiscussGroup=3

McConnell: 25% isn't necessarily a bad number. What's bad about it is that the average project is something like 100% late and 100% over budget at the time it's shut down. With better development approaches, a lot of those projects would get shut down when they've used 20% of their budgets rather than 200% of their budgets.
http://blogs.cio.com/node/600

Schedule chicken , someone leave the responsiblity to other sliencely - http://www.stickyminds.com[..]ion=edetail&ObjectType=COL&ObjectId=7923

If you need to deliver software in 9 months, you could make a plan to deliver software in 9 months and hope it works. Or you could start delivering software every week. Maybe in the first week you aren't so good at it but after four weeks you and the rest of your team will be better. I call it the reduce risk by practicing technique. I can't believe how many people line up against me on this, even quality experts. - Ward Cunningham

Estimate via experience - http://digerati-illuminatus.blogspot.com[..]mating-software-feature-development.html

Explain what is Velocity in scrum - http://kw-agiledevelopment.blogspot.com[..]2008/01/understanding-your-velocity.html

Concern about estimation - http://agile.dzone.com/news/humans-cant-estimate-tasks http://jimhighsmith.com/2011/11/02/velocity-is-killing-agility/

Test Effort Estimation - http://blogs.siliconindia.com[..]mation_approch-bid-00oQI1TW93593159.html

Reducing focus on estimation, I think it is good move, as estimate always inaccurate - http://blog.anandvishwanath.in[..]se-for-reducing-focus-on-estimation.html

(google search) (amazon search)

Sat Nov 05 08:26:05 HKT 2011 From /weblog/software_engineering/SCM

structure aware

Refactoring-aware SCM System - https://netfiles.uiuc.edu/dig/MolhadoRef/molhadoref.html

Discussion about structure of subversion respository, and the effect to the project - http://blogs.wandisco.com[..]t-practices-repository-structure/?=kt_tw

(google search) (amazon search)

Fri Nov 04 23:15:46 HKT 2011 From /weblog/software_engineering/team

confilct

No problem is a big problem, So we want to actually encourage conflict in the sense of encouraging openness about disagreement, which in turn suggests that it is essential that we are prepared to resolve conflict - http://jchyip.blogspot.com[..]0/conflict-will-and-should-occur-be.html

(google search) (amazon search)

Fri Nov 04 01:41:15 HKT 2011 From /weblog/software_engineering/testing

exploring test

Using mindmap as testing tool - http://lisacrispin.com[..]02/28/using-mind-maps-for-test-planning/

Chat about exploring test - http://www.developsense.com[..]g-or-scripted-testing-which-comes-first/

How to effective use notebook with exploratory-testing - http://www.developsense.com[..]4/exploratory-testing-recording-and.html


(google search) (amazon search)

Sun Oct 30 02:10:07 HKT 2011 From /weblog/software_engineering/testing

TDD

If you write the test after you've written the code, it's much more likely that you'll write the tests that will pass what you've written.

That's just how our brains work.

If you determine the criteria for whether a decision is good after you've already made the decision, it's much more likely that you'll create criteria that justifies the decision that was just made.

That's just how our brains work.

Determine how to assess whether something is good before you implement it and/or before you make a decision. Otherwise, you will tend to be emotionally attached to what you just did, what you just decided.

http://jchyip.blogspot.com/2011/09/criteria-first.html

My Top 5 ways to reproduce a "Hard to Reproduce" Bug! - http://software-testing-zone.blogspot.com[..]/my-top-5-ways-to-reproduce-hard-to.html

Common TDD issue and suggested solution - http://www.agileadvisor.com[..]utomated-test-problems-address-root.html

http://biblio.gdinwiddie.com[..]om/biblio/StudiesOfTestDrivenDevelopment

http://www.notesfromatooluser.com[..]ptions-with-test-driven-development.html

(google search) (amazon search)

Thu Oct 27 00:55:23 HKT 2011 From /weblog/software_engineering

retrospective

Goal driven retrospective - http://fabiopereira.me/blog/2008/11/23/goal-driven-retrospective/

appreciative retrospective, find out what good and seek more - http://www.ayeconference.com/appreciativeretrospective/

reason of doing this - http://www.markhneedham.com[..]log/2011/10/24/retrospective-the-5-whys/

(google search) (amazon search)

Thu Oct 27 00:12:55 HKT 2011 From /weblog/software_engineering/team

leadership

Keep focus, or lose - http://googlesystem.blogspot.com[..]0/how-steve-jobs-influenced-googles.html

The anti-pattern and suggestion about new joiner - http://5whys.com[..]-you-will-face-as-a-software-team-l.html

Believe me, the objective was not to make decisions, but to create the right environment so that the right decision would be made. http://tech.groups.yahoo.com/group/leandevelopment/message/1952

A nice set of questions to ask for a leader - http://jchyip.blogspot.com[..]3/questions-on-influence-and-growth.html

In short, don't put your shoes on others' foot - http://www.inc.com[..]earned-in-the-army_Printer_Friendly.html

4 types of leadership style, well, I think he model leadership a little too simple - http://softwarecreation.org[..]s-the-best-leader-for-the-software-team/

Servant Leadership - http://www.inc.com[..]t-be-my-style-of-servant-leadership.html

Your experts are spending all their time mentoring novices. Therefore:

Put one expert in charge of all the novices, let the others develop the system. - http://gigix.agilechina.net[..]010/2/25/organizational-pattern-day-care

What is the key Characteristics of great team - http://www.infoq.com/news/2011/01/characteristics-agile-org

This is very insightful obversation, in many time we look into something work in short term but not really solve the problem, a discussion about why so many people like micromanagement even if they know it is bad - http://www.thoughtclusters.com[..]m/2011/01/programmers-and-micromanaging/

http://www.adoptionofagile.com[..]best-thing-you-can-do-for-your-team.html <- is provide required information, probably more transparent.

Don't make me think... but you have no business not allowing me to think if I choose to. - http://jchyip.blogspot.com[..]allow-me-to-think-just-dont-make-me.html

How To Lead Clever People, actually I am double about this, let's see - http://business.in.com/printcontent/28632 http://business.in.com/media/images/2011/Sep/img_56852_wise.jpg


(google search) (amazon search)

Wed Oct 19 20:30:50 HKT 2011 From /weblog/software_engineering/team

work from home

work from home guideline from sun - http://blogs.sun.com[..]y=designing_from_anywhere_best_practices

Comment about working as independence consultant, a good reading that discuss some issue at HK or China limited this area of jobs - http://blog.nona.name/200801251.html

10+ productivity tips when working from home, in summary, treat is as office - http://www.codeforest.net[..]productivity-tips-when-working-from-home

(google search) (amazon search)

Sat Oct 15 11:19:00 HKT 2011 From /weblog/software_engineering

review

Why code review beats testing: evidence from decades of programming research - http://kev.inburke.com[..]the-best-ways-to-find-bugs-in-your-code/

1: Review often
2: Review informal and short
3: Review with difference people
4: Keep it positive
5: Enjoy it

http://www.makinggoodsoftware.com[..]/08/06/5-tips-to-make-good-code-reviews/

(google search) (amazon search)

Sat Oct 08 20:28:34 HKT 2011 From /weblog/software_engineering

scrum

Experience of adopting scrum - http://www.ericsink.com/entries/agile_2011_paper.html

Comparison of XP and Scrum - http://jamesshore.com/Blog/Should-We-Adopt-Scrum-or-XP.html


(google search) (amazon search)

Tue Oct 04 00:22:03 HKT 2011 From /weblog/software_engineering/testing

performance

By far the biggest reason I have seen for the performance discrepancy above is not due to a faulty test but due to the stress test being executed on wildly different data sets than what is in production. - http://saasinterrupted.com[..]on-flaw-in-software-performance-testing/

http://www.jayphilips.com[..]0-open-source-performance-testing-tools/

Discuss about performance management, a process to monitor and control performance details - http://blog.dynatrace.com[..]1/09/15/why-do-you-do-apm-in-production/

(google search) (amazon search)

Tue Oct 04 00:09:14 HKT 2011 From /weblog/software_engineering/project

project management

Linus share about project management, most importance is people, and also discuss about tools, how to collabrate people and how to delegate - http://h30565.www3.hp.com[..]Software-Development-Management/ba-p/440

Only the programmer who is going to write the code can schedule it. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to do the work can figure out what steps they will need to take to implement that feature. - http://www.joelonsoftware.com/articles/fog0000000245.html

Never, ever let managers tell programmers to reduce an estimate. Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. - http://www.joelonsoftware.com/articles/fog0000000245.html

Micromanagement or Macromanagement? http://boncey.org/2006_10_29_how_to_mentor_programmers

But, unfortunately, as a general rule, Project Managers have no training. Even if they do have training in the form of an MBA, MBA education is impractical and useless; the academic community has completely failed us in this respect. Furthermore, Project Managers are more often based on personal friendships and company politics; they are rarely based on management skill.
And, finally, most managers do not acknowledge that management is a skill that they must study and learn so they don't study or learn it.

http://discuss.joelonsoftware.com[..]DiscussTopicParent=8469&ixDiscussGroup=5

An explanation of agile, I think it is more about project management - http://blog.objectmentor.com/articles/2007/04/23/short-reach

Some common problem of software project management - http://ajaxwidgets.com[..]thomas/9_reasons_why_software_project.bb
http://ntschutta.com[..]ou-know-your-project-is-in-trouble-when/

http://www.goodproductmanager.com[..]roduct-management-vs-project-management/

Brief description of thoughtworks codejam - http://blog.nona.name/200804274.html

Listen first. Measure later. http://digerati-illuminatus.blogspot.com[..]gspot.com/2008/05/measure-or-listen.html

Paper of burn up and burn down - http://alistair.cockburn.us/Earned-value+and+burn+charts Per my understanding, we can say burn down is push by management where DEV work as task consumer and completing per define tasks within limited time; where burn up work in the other way round.

Why rewrite usually bad - http://www.jroller.com[..]astianKuebeck/entry/why_version_2_0_will

Why need to manage user/client - http://dreamhead.blogbus.com/logs/48408290.html

The blog list several software projects fail case study - http://www.codinghorror.com/blog/archives/000588.html

The law of late project - http://www.commonsense4commonpeople.net[..]et/2009/11/the-law-of-late-projects.html

Friendship, what make one big team working - http://blog.objectmentor.com/articles/2010/04/26/pair-management

On an Agile Team, a person is removed from the team by assigning them work. - http://www.agileadvice.com[..]e-between-agile-teams-and-project-teamd/

(google search) (amazon search)