download zip of files only
Tue Nov 12 12:09:43 GMT 2019
From /weblog/software_engineering/team
Recently I help the company offshore some work to CN developers, many difficulty I've encounter, most difficult one is it is hard to share the vision and big picture to CN developers. This article mention a few good notes http://martinfowler.com/articles/agileOffshore.html , the one I think I am lacking is having short meeting with them often. I will see if we can have video conferencing so that we are easier to meet. The other tips here - http://www.theserverside.com[..]_id=45367&asrc=EM_NLN_1439070&uid=703565 but I think the tips list is too long and probably only apply to large enterprise Tips of communication with offshore team - http://www.acceptic.com[..]on-in-software-development-projects.html http://martinfowler.com/articles/remote-or-co-located.html https://www.infoq.com/articles/top5-problems-distributed https://www.infoq.com/articles/be-agile-distributed-teams http://www.infoq.com/cn/articles/be-agile-distributed-teams https://angel.co[..]ur-remote-team-and-then-getting-it-right
(google search)
(amazon search)
Thu Aug 22 00:00:00 GMT 2019
From /weblog/software_engineering/testing
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 Basically, we should keep it simple, and driven the development rather than post test - http://blogs.telerik.com[..]stteam/Posts/13-01-24/top-5-tdd-mistakes A good list of anti-pattern - https://techblog.betclicgroup.com[..]2014/05/06/getting-unit-testing-to-fail/ Test rely on shell script return is difficult to maintain, say the script running at background can cause problem - http://stuartmarks.wordpress.com[..]m/2014/01/10/another-shell-test-pitfall/ Six Things That Go Wrong With Discussions About Testing - http://www.satisfice.com/blog/archives/1728 https://codurance.com/2019/08/21/seven-testing-sins/
(google search)
(amazon search)
Mon Apr 29 02:54:01 GMT 2019
From /weblog/software_engineering/testing
Customer attitude will affect how the software engineering workflow a lot: http://groups.yahoo.com[..]gprog/message/7420?threaded=1&var=1&p=24 Do you think this piece of code are too simple to have test case to cover? read this - http://gojko.net[..]t-the-software-craftsmanship-conference/ Related blog, finding the common between taking photo and software testing - http://andreas-simon.blogspot.com[..]hotographic-testing-lessons-learned.html . However, there is one big difference, it is harder to define a good photo than bug feel software If it is good to put developer as tester? - http://janetgregory.blogspot.com[..].com/2011/03/programmers-as-testers.html In fact I am kind of agree about this article, but maybe I just not TDD hard enough - http://beust.com[..]ectural-meltdown-around-iteration-three/ Tooling, Insight and Humility - http://www.developsense.com[..]reasons-for-testers-to-learn-to-program/ Insufficient Requirements is not an excuse - http://www.developsense.com[..]-blog-posts-9-insufficient-requirements/ What is the meaning of working - http://www.developsense.com[..]14/03/very-short-blog-posts-14-it-works/ How Much is Enough? Testing as Story-Telling - https://www.satisfice.com/blog/archives/6203
(google search)
(amazon search)
Tue Apr 09 10:38:55 GMT 2019
From /weblog/software_engineering/testing
Yet other discussion of Stubs, Fakes, and Mock Objects - http://vladimirlevin.blogspot.com/2007/11/stubs-fakes-mocks.html http://www.sustainabletdd.com/2012/05/mock-objects-part-1.html While reviewing this article, Marty Andrews pointed out an important insight: there are two ways to use a mock object, either as a testing technique or as a design technique, and the intended use helps shape the available choices. http://www.onjava.com/lpt/a/4526 Someone post some arguement that using mock probably a bad idea , which look like a endless arguement... - http://jroller.com[..]xRuiz?entry=mocks_for_concrete_class_can Alberto Savoia on Testing the Untestable, raise a point that mocking make testing more portable, it probably true, but database setup may be not that difficult to port. - http://www.artima.com/forums/flat.jsp?forum=276&thread=213402 http://gojko.net[..]ut-isolation-but-about-responsibilities/ http://blog.objectmentor.com[..]ing-the-invasion-of-dots-and-parentheses Fakes should have their own tests - http://googletesting.blogspot.com.au[..]/testing-on-toilet-fake-your-way-to.html http://lkrnac.net/blog/2014/01/18/mock-final-class/ Again, other post on pros and cons for difference approach - https://codurance.com/2019/04/08/Introduction-to-test-doubles/
(google search)
(amazon search)
Thu Jul 26 15:47:33 GMT 2018
From /weblog/software_engineering
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 http://www.scrumexpert.com[..]ng-budget-instead-of-estimates-in-agile/ Discussion about noestimates-software-contractors - http://www.infoq.com[..]2016/01/noestimates-software-contractors http://www.infoq.com[..]2015/12/noestimates-software-contractors https://ronjeffries.com/articles/estimation-articles/ https://ronjeffries.com/articles/018-01ff/no-estimates-logic/
(google search)
(amazon search)
Wed Jun 06 03:59:50 GMT 2018
From /weblog/software_engineering/project
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/ Some say an method "Impact Mapping" is very useful - http://mysoftwarequality.wordpress.com[..]com/2014/07/15/complexity-is-the-excuse/ Transfer project to products - https://www.infoq.com/articles/transform-projects-products Frequent planning - https://www.jrothman.com[..]can-lead-to-short-and-frequent-planning/
(google search)
(amazon search)
Sat Feb 24 16:23:55 GMT 2018
From /weblog/software_engineering/team
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 Should DEV work in prod? - http://swreflections.blogspot.hk[..]developers-working-in-production-of.html
(google search)
(amazon search)
Fri Jan 06 14:08:55 GMT 2017
From /weblog/software_engineering/team
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 A methodology to test the feeling of the team - http://www.codinghorror.com[..]2/12/web-discussions-flat-by-design.html It is the most important skill for programmer - http://chodounsky.net[..]/the-most-important-skill-of-programmer/ and also there are pointer of how to improve your communication skill Slack is good? - https://engineering.policygenius.com[..]per-day-on-slack-29f8b08c0d82#.l27wrcft0
(google search)
(amazon search)
Thu Feb 18 03:12:52 GMT 2016
From /weblog/software_engineering
Examples of stories - http://www.captaindebug.com/2013/06/so-whats-in-story.html Introduction to story point - http://blog.anandvishwanath.in[..]in/2011/03/questioning-story-points.html Imperative vs Declarative Scenarios in User Stories - http://benmabey.com[..]clarative-scenarios-in-user-stories.html Turn good story to great 1. Get your story right 2. The unwritten rule of what goes inside 3. Choose your words carefully 4. Use acronyms sparingly 5. Convention over OVER-complication - http://jcwong.wordpress.com[..]8/08/turning-stories-from-good-to-great/ Checklist for user story - http://marjoriepries.blogspot.com.au[..]hecklist-for-effective-user-stories.html See the picture in your backlog. - http://winnipegagilist.blogspot.ca[..]012/03/how-to-create-user-story-map.html INVEST mnemonic to describe the characteristics of good stories: Independent: the stories can be delivered in any order Negotiable: the details of what's in the story are co-created by the programmers and customer during development. Valuable: the functionality is seen as valuable by the customers or users of the software. Estimable: the programmers can come up with a reasonable estimate for building the story Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration. Testable: you should be able to write tests to verify the software for this story works correctly. http://martinfowler.com/bliki/UserStory.html Story Mania, User Incognito, Disastrous Details, Story Handoff, Criteria Crisis - http://www.romanpichler.com[..]er-stories/5-common-user-story-mistakes/ Define Motivations, Don't Define Implementation - http://alanklement.blogspot.de[..]replacing-user-story-with-job-story.html Why large team is not suitable to use user story to collect requirement - http://accelerateddevelopment.blogspot.hk[..]/07/user-stories-dont-work-for-most.html How to split stories - http://gojko.net[..]tting-user-stories-the-hamburger-method/ Visually mapping story to backlog - https://www.thoughtworks.com[..]ping-visual-way-building-product-backlog
(google search)
(amazon search)
Thu Jun 11 03:41:22 GMT 2015
From /weblog/software_engineering
The crucial bridge between theory and practice is called execution - http://abdullin.com[..]l/2012/2/22/importance-of-execution.html 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 Discussion about various issue when thing change - http://swreflections.blogspot.com.au[..]ankensystems-half-strangled-zombies.html http://www.opsbs.com[..]-patterns-in-development-and-operations/ http://www.yegor256.com[..]/06/08/deadly-sins-software-project.html
(google search)
(amazon search)
Thu Apr 09 04:10:12 GMT 2015
From /weblog/software_engineering/testing
How to write unit test for RCP application in eclipse - http://www.notesfromatooluser.com/2007/06/developing-ecli.html http://nricheton.homeip.net/?p=94 and functional robot tester - http://ketan.padegaonkar.name[..]ame/2007/12/18/announcing-swtbot-01.html A lot of links of tools - http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications CI for eclipse RCP - http://www.pluginbuilder.org/ Don’t write E2E tests instead of UI tests. Instead write unit tests and integration tests beside the UI tests. Hermetic tests are the way to go. Use dependency injection while designing your app. Build your application into small libraries/modules, and test each one in isolation. You can then have a few integration tests to verify integration between components is correct . Componentized UI tests have proven to be much faster than E2E and 99%+ stable. Fast and stable tests have proven to drastically improve developer productivity. - http://googletesting.blogspot.com.au[..]015/03/android-ui-automated-testing.html
(google search)
(amazon search)
|