22.12.14

"Side effect" of unit tests

Sometimes the test itself doesn't do much. It maybe simply tests something very minor. However, implementing the unit tests will force us to make sense of the code.

Today I tried to create a unit test for a DAO class. I had to keep on refactoring the code until I can write simple test for it:


  • Simple mock object.
  • Easily definition of the purpose in test.
The test itself turned out to be very trivial, but the source code for the business logic make a lot better sense to me and others.

17.12.14

Somebody help Wikipedia please.

I fully understand that Wikipedia needs money to run the services. But dude, you need to know that the way you are asking money is very much disturbing. More frustratedly, after I donate money, the huge banner will still show up, at least that happened before.

Why don't you just bring in some commercial sponsors? Google AdSense or whatever it is. The way you are asking money is not better than putting a commercial on the website.

5.12.14

Keep Cygwin Applications from setting NTFS security descriptors

http://blag.nullteilerfrei.de/2014/04/07/keep-cygwin-applications-from-setting-ntfs-security-descriptors/

My tip is to avoid this by making cygwin not set any permissions at all. If a cygwin application then creates a file, for instance, this file will only inherit its security settings from the folder it is contained in.

https://cygwin.com/cygwin-ug-net/using.html#mount-table

 noacl     - Cygwin ignores filesystem ACLs and only fakes a subset of
       permission bits based on the DOS readonly attribute.  This
       behaviour is the default on FAT and FAT32.  The flag is
       ignored on NFS filesystems.

Don't mix NFS with NTFS. :-(

2.12.14

Clarify, Simplicity, and Abundance

Like this statement from "Thrift: Scalable Cross-Language Services Implementation"


The type system rests upon a few base types. In considering which types to support, we aimed for clarity and simplicity over abundance.


Similar to less is more

11.11.14

Love the ShopSafe Feature of BoA

I wish all credit card companies should provide this feature. Really helpful!!

27.10.14

Javascript闭包


书中定义:
  • P180
  • This combination of a function object and a scope (a set of variable bindings) in which the function's variables are resolved is called a closure in the computer science literature.
    • This is an old term that refers to the fact the function's variables have bindings in the scope chain and that therefore the function is "closed over" its variables.

19.10.14

手把手教你开发chrome扩展


  • http://www.cnblogs.com/walkingp/archive/2011/03/31/2001628.html
  • Getting Started - From Official Website

21.9.14

Agile Delivery vs. Prototyping

  • Dan George
    Dan
    Principal Software Engineer at Grass Valley, A Belden Brand
    In a sense, your colleague has it right. Software is an example of production via prototype replication. We create the original, replicate it and distribute the replicas. However, I doubt that's what he meant.

    He probably thinks of a prototype as something that demonstrates some attributes of the real thing but not all. If this is his definition then he is missing that what is delivered at the end of the sprint *is the real thing*.

    In the late 80's and into the 90's we learned that sw prototypes were relatively expensive compared to the real thing. HW prototypes usually serve their purpose at much less cost than creating a real thing. Not so for sw. Also, too often the sw prototype seemed close enough and was shipped. The quick-n-dirty code lacked non-functional features and was costly in the long run.

    This ties into the value of documentation. If prototypes were expensive, why not just document what the product will look like and then build it? Well, turns out we are not so good at describing a software product on "paper." We can do screen-shots and such but over time we realized that documenting the product was less useful than prototyping and almost as expensive (or even more expensive).

    As much as we wish we were effective at validating the product on paper, we cannot seem to do it. We have to create a functional program to validate it. We learned that developing something that is functionally close, but lacking non-functional characteristics, was too expensive. We have to build it right the first time (ironic, eh?). Since we have to go to the extent of meeting both functional and non-functional requirements, we had better make sure we are building the right thing. Thus, we build it in small functional steps that are implemented well. Theoretically, we should be able to come up with something more efficient but every attempt as been less efficient or ineffective (or both).
     Leo R.Steve B. like this

16.9.14

The Diva Discussion in LinkedIn

I found this topic in the recent discussion in LinkedIn very interesting:

Dealing with Solo stars

Gets the job doneTop Contributor
OK, we've all seen divas in IT.

So let's assume you got a newly formed team and there's 3 guys working really hard to chunk up some basic domain expertise and deliver some value.

Then the CEO decides, without asking the team, to add one diva (with superior domain knowledge) to the team who neither participates in plannings nor standups, who prefers not to share any information unless explicitly asked and refuses to use collaboration tools like Jira, git or Jenkins.

Of course, the diva doesn't feel responsible to anyone and would rather tell the CEO that these guys are all idiots than to integrate and blend with the team.

What would you do?

    And I especially agreed with what Thad Scheer said and would like to share here for future references:

    • Thad Scheer
      Thad
      Managing Partner at Sphere of Influence
      Everyone's beating up on this poor CEO and "diva". I'll take the contrary point of view and side with them.

      The OP says "3 guys working really hard", that's different than "3 guys totally slaying the dragon". Maybe these guys are working hard but going nowhere fast? Maybe they aren't actually working hard relative to the CEO's work ethic? Maybe the bar within the organization has gotten lower over the years? Perhaps it's time to bring in a pro who knows what to do next, puts boot to ass, and gets stuff done?

      This person will make the locals look bad by comparison and will ruffle feathers. She doesn't attend their feel-good happy meetings and doesn't play their silly Agile games. She's laser beam focused on putting points on the board by developing software. The message is "don't step up if you can't keep up".

      The CEO is delighted with her performance because now the important things are finally getting done, things that matter to corporate strategy.

      In the end, the 3 guys are in the wind and the solo star will hire her own team comprised of people cherry picked by her to get things done. Arising out of the ashes is a new team harmony, not the old one built around feel-good happy meetings but a new one built around strong individual contributors, effective professional relationships, and a focused team-level dedication on execution.

      Is that so bad?

      Maybe she's not a diva, maybe she's Wonder Woman?


    This is my comments.

    • Jeff Huang
      Sr Software Architect / Sr Principal Software Engineer at CA Technologies
      @Michael I think you oversimplified what happened between the Diva and the team. How about asking the Diva the following questions:

      1. Do you want to work in this team? If no, why?
      2. Did you tried to work with the team? If yes, how? If no, why?
      3. What would be the best way to work with this team to his own opinion?

      Other than these general questions, you can also ask some more specific questions. For example:

      *. What is the reason that prevents you from using the collaboration tools? Ask him one by one. Do you have any other recommendations for the tools?

      Admittedly, some people are more team oriented, and some are not. But as long as they want to help the team, you can find a way to make it work. More importantly, the Diva is a real expert with superior domain knowledge, that's what matters.

      In fact, the Agile framework, IMHO, was designed to help fit those Diva into the team better.


    12.9.14

    What is Agility?

    I really like the Agile Manifesto:

    Individuals and interactions over Processes and tools
    Working software over Comprehensive documentation
    Customer collaboration over Contract negotiation
    Responding to change over Following a plan
    That is, while there is value in the items on the right, we value the items on the left more.

    To me, being Agile is a very natural thing: to develop successful software products. And I define successful software products in a very simple way:
    • A software product can be sold, and continuously sold successfully.
    Although this is not applicable to open source software, but I still like it.

    27.8.14

    'detached HEAD'

    
    $ git checkout camel-2.13.1
    Checking out files: 100% (2493/2493), done.
    Note: checking out 'camel-2.13.1'.
    
    You are in 'detached HEAD' state. You can look around, make experimental
    changes and commit them, and you can discard any commits you make in this
    state without impacting any branches by performing another checkout.
    
    If you want to create a new branch to retain commits you create, you may
    do so (now or later) by using -b with the checkout command again. Example:
    
      git checkout -b new_branch_name
    
    HEAD is now at b64d181... [maven-release-plugin] prepare release camel-2.13.1
    

    [dz]: Java 9 Features Announced — What Do You Think?

    http://java.dzone.com/articles/java-9-features-announced

    [dz]: Traditional Log Management Is Dead. Long Live Autonomic Analytics!

    http://java.dzone.com/articles/traditional-log-management
    http://java.dzone.com/articles/another-spring-boot

    19.8.14


    • http://www.telecomabc.com
    • http://www.cenx.com/technology/standards.html
    • http://4g-lte-world.blogspot.com/2012/05/default-bearer-dedicated-bearer-what.html
      • Default Bearer, Dedicated Bearer... What exactly is bearer ?
    • http://en.wikipedia.org/wiki/Picocell

    5.8.14

    JDK 1.7.0_40 or newer - Oh yeah!

    [INFO] --- maven-enforcer-plugin:1.1:enforce (enforce-java) @ jetty-project ---
    [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
    [ERROR] OLD JDK [1.7.0_09] in use. Jetty 9.2.2.v20140723 requires JDK 1.7.0_40 or newer

    https://webtide.com/jetty-9-features/
    Java 7 – We have removed some areas of abstraction within jetty in order to take advantage of improved APIs in the JVM regarding concurrency and nio, this leads to a leaner implementation and improved performance.

    Test or Verification?

    Have been in some discussion of system testing. System testing is important, no doubt. But system testing is not a guarantee of software quality, not even close - that has been proved for a long time, before the Agile movement, mostly because that system testing consumes so many resources while the path coverage was so limited. We could use system testing to make sure all components or units of the system are in place correctly. But if you rely on system testing, such as longevity, Minimal Acceptance Test, and regression tests to guarantee the quality? You are in trouble. In some extreme view angle, if system tests help find a lot of defects in your product - that means you have serious software quality issue.

    System test, sometimes calls end-to-end test. In most of the case, we put the system in a certain test environment, with everything set up properly, run a subset of system features in a certain order or have people access the system in a certain way. For a certain period, we look into the system and see whether it is running alright.

    • We need to set up the system. That could be tiresome and time consuming.
    • We need to set up the system properly - that means we can only test the happy path.
    • We need to drive the test in a certain way, either manually or automatically.
    Here come the problems:
    • It will take time. Maybe minutes, or hours, or even days. If there are intermittent defects, it may take weeks or months or even longer to have the problem show up. It doesn't look too bad until we put it into the release cycle. How many minutes, hours, or days we have in a release cycle?
    • We could have some edge cases tested in our system, but most of the time we are testing the happy paths. How often that we have problems in the happy path? That means we are waiting our time. More importantly, that also means that coverage of the test is so poor that we can't build up our confidence, many defects would remain unknown and slip to the customers.
    • Manual tests consume a lot of resources.
    • Some team build up automation for system tests. That's a good thing. But automatic end-to-end test is not easy to build. It takes time also. Some teams just simply fail the mission for spending too much time on this area. I was there before.
    A better solution would be integration tests. Along with some level of system, end-to-end test, we also test smaller modules of the system. This is a good one and I like it.
    • Having smaller modules that could be testable means the system is decoupled properly. It will foster the idea of decoupling in the long run.
    • We can mock some input, output, or database connection to make sure we have good coverage of the code paths. Those are not likely possible in end-to-end testing.
    • With smaller piece of the software, usually we can build up the test environment quicker and the test cycle will be shorter.
    I personally like Integration Test. 

    The most important, and most wildly recognized test type is unit test. As much as I like integration test, I rely on unit tests for system quality for the following reasons:
    • It is extremely fast. A typical unit test take milliseconds, by comparing to integration test as seconds or more. It is usually a bad sign if we have unit test that runs for more than a second.
    • It can, and should be done along with the coding cycle by the same engineer, and it will be review later and evolved along. In this way, code path can be covered well.
    • The AAA pattern for unit test makes sure we don't overkill the test. If we don't follow, or find it is hard to follow the AAA pattern, it is a good time to review your code and do some refactorings.
      • A - Arrange
      • A - Assign
      • A - Assert
    • And yeah, unit test will help recognize the chance for refactorings and help verify the refactorings. Some awfully built unit tests add a lot of burden for refactoring the original code, that is obviously a bad sign for bad unit tests, and bad software quality. If you see this, you'd better rebuild the test. Simply get rid of the test and rebuild them could be a solution if you don't see a better one.
    • TDD - I use TDD, but not always. I can see the value of it especially with those teams that  has been using this practice successfully. But my personal style would be that last-mile-driven-development. That means I built up my solution very quick in the way I feel comfortable with, sometimes TDD, sometimes not. For the last mile, I begin building some tests, not necessary unit tests, to drive my implementation. After that, I will build more unit tests to cover my code along with some necessary refactorings.
      • Software engineering is a balance of idea and engineering. TDD is a good thing for ensure the engineering part. But constantly switch from business code and test code will create unnecessary interruption and that is not good for the idea part. So I would rather have the idea flow out smoothly until I hit the engineering necessity.
      • Sometimes I simply begin with a Hello World program, build up all the happy path, along with some edge cases if I can come up with. Then I review my implementation and make sure they work well. Like I said, I don't want to interrupt myself when focusing on the "idea" part. Reviewing the implementation will guarantee the finally quality, and refactorings and unit tests will help assure that.
    Other than End-to-End test/System tests, Integration Tests, and Unit Tests, I also like the quick test for some unknown issue. 
    It is almost a common sense that we should test a certain solution with minimal effort but thorough test. However, sometimes people don't do that. For example, how can we make sure a new JVM parameter work for our system? Some teams might put the new JVM parameter into the system and have it run for a while. If the system is happy, then use it. Oh, that doesn't sound right, do it? We should build up a simulation environment and verify the parameter to make sure how it works before we even put it in place. There will be a good chance that your happy path test doesn't reveal anything and the problem slips to your customer.

    When my team had a big problem with JMS bus, I built up a SWAT team of three to find out a valid solution. That was a great journey and we successfully deliver our solution and helped the product for its first GA. The secret of my SWAT team was that we simulate our communication model and built a very simple ActiveMQ problem to verify those configuration options, based on the messaging theories. To be honest, none of us were JMS experts at that time. But a week of thorough tests, we found out the solution that the team needed and deliver it with high confidence.

    But why some teams don't do that? Here are the reasons I can think about:

    • Not able to abstract the test goal into a simulation.
    • Lack of confidence. Usually caused by low quality of the products.
    • Politics of the development team - afraid of making decision based abstraction or simulation environment.
    That the way I value different kinds of tests.



    23.6.14

    [Link and Note] : Media draining battery? media process android SOLVED




    Solution: If you are running jellybean and notice the media process running and would like to end it's reign on your battery/ram...simply go to apps>all, scroll down to DOWNLOAD MANAGER, and click on it, scroll down to clear data and select ok. This won't harm anything, what it does is stops the media process from running a loop. I wanted to make this post so those out there like me who spent days trying to figure out the source of this running process could finally have an easy, viable answer!

    5.6.14

    Innovation or Reinventing the Wheel?

    Today my team have a demo on a new feature. It is a feature that was built upon OData. We all got excited about this feature. One of the most exciting things is that we can find tools online to help us extend our feature.

    Back to the day when the project began, we had a prototype/solution that was recognized as very creative, which was built upon some internal solution. I don't have problem with home-grown solution, we do it all the time. However, I identified that this home-grown solution had problem of coupling some non-extensible feature. As an architect, I always suspect this non-extensible part could face massive re-design sooner or later, so I asked the team to hold on a little, and to see whether there were other alternatives.

    One of my colleagues proposed the OData based solution. We began to investigate on this solution and finally reached to consensus. Besides the tightly coupling issue, I envisioned the OData solution would give us benefits of using an open standard. Now when we saw the demo, we all realized the investment began to pay off.

    We are in an industry that requires innovative ideas. However, software still relies on engineering. Reusability, cooperation, extensibility are all features we need for software engineering. When we think about ideas, we can think as innovative as possible. But when we are thinking about implementation, open-standards are our friends. I usually pay some attention to those innovative implementation.

    But don't get me wrong, I really like innovative ideas as well as innovative implementation, because implementation is also kind of idea. But still, we need to balance that, and see whether we can leverage our existing knowledge or tools, which include open-standards.

    26.3.14

    25.3.14

    Build a Complete MVC Website With ExpressJS - Tuts+ Code Tutorial


    PostgreSQL and Mac OS X and NodeJS


    http://broabandtrafficmanagement.blogspot.com

    开源网管系统比较

    http://os.51cto.com/art/201307/402538_all.htm

    在本系列文章中,我们将一同剖析四款高人气开源产品--Nagios Core 3.5、NetXMS 1.2.7、OpenNMS 1.10.9以及Zenoss Core 4.2。四款产品都已经相当成熟,足以提供与其它企业级同类方案相媲美的综合性监控能力,同时拥有良好的社区支持体系。
    四款产品都提供管理、性能监控以及网络设备警示与报告功能,其作用范围涵盖服务器、路由器、交换机、打印机、UPS、网络站点、业务应用程序以及移动设备等等。监控功能可以简单起效,用户可以像使用PING请求那样利用SNMP(即简单网络管理协议)或者本地代理对单一设备进行全面管理。
    此次参与评述的四款产品经实测全部支持SNMP及其它通用型协议,包括WMI、HTTP、SMTP、SSH以及XML。尽管其中两款产品只能用于特定操作系统,但四者全部可以实现跨平台IT基础设施监控(本质上说可作用于任何拥有IP地址的设备)。它们支持的功能包括自动识别、SNMP、可阅读系统日志、触发器/警报设置、Web应用程序、分布式监控(即负载平衡)、映射、IPv6(只有NetXMS不支持IPv6)以及库存追踪。
    四款产品还提供基本而全面的基础设施监控功能,而且很少甚至完全不需要额外硬件、内存以及存储机制作为监控环境的支持基础。在本次评述中,我们将从安装便捷性、配置便捷性、管理能力、多平台支持能力、报告机制及总体可用性等几个角度做出横向比较。

    21.3.14

    Mashup

    http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

    20.3.14

    Wi-Fi Offload

    http://www.aptilo.com/mobile-data-offloading/wifi-offload-3g-4g

    Carrier Ethernet

    http://en.wikipedia.org/wiki/Carrier_Ethernet

    Carrier is a marketing term for extensions to Ethernet to enable telecommunications network providers ("common carriers" in US industry jargon) to provide Ethernet services to customers and to utilize Ethernet technology in their networks.



    Line Card


    • http://en.wikipedia.org/wiki/Line_card
    • http://www.pcmag.com/encyclopedia/term/46105/line-card
    • http://www.cscprinters.com/line-card.html
    • http://www.cscprinters.com/line-card.html

    The Concept of OTT

    http://en.wikipedia.org/wiki/Over-the-top_content

    Over-the-top content (OTT) refers to delivery of video, audio and other media over the Internet without a multiple system operator being involved in the control or distribution of the content. The provider may be aware of the contents of the Internet Protocol packets but is not responsible for, nor able to control, the viewing abilities, copyrights, and/or other redistribution of the content. This is in contrast to purchase or rental of video or audio content from an Internet service provider (ISP), such as pay television video on demand or an IPTV video service, like AT&T U-Verse. OTT in particular refers to content that arrives from a third party, such as NowTVNetflixWhereverTVHuluWWE NetworkRPI TV or myTV, and is delivered to an end user device, leaving the ISP responsible only for transporting IP packets.
    An online video distributor (OVD) is defined as "any entity that offers video content by means of the Internet or other Internet Protocol (IP)-based transmission path provided by a person or entity other than the OVD."[1]
    Over-the-top messaging refers to a similar idea, where a third party provides instant messaging services as an alternative to text messaging services provided by a mobile network operator.[2]
    Consumers can access OTT content through internet-connected devices such as desktop and laptop computers, tabletssmartphones including iPhones and Android phones, set-top boxes such as the Roku andGoogle TV smart TVs and gaming consoles such as the WiiPlayStation 3 and Xbox 360. Consumers can access apps in most app stores.
    DTAG announces New Multi-Device OTT Video Acceleration Platform LiveStream Perform With Octoshape [3]
    WWE has launched its new OTT network, dubbed the WWE Network, as of February 24, 2014.[4]
    ANTIK Telecom launched its new OTT network under brand SmartTVBox, using their own Juice Media Server HLS streaming platform, on August 1, 2012[5]
    PBS is testing the waters for streaming their content OTT to consumers via a Roku channel.[6]
    Australia's Foxtel pay-TV provider launched their Foxtel Play[7] service on August 1, 2013.[8]
    Findings from market intelligence firm ABI Research show the OTT video market passed $8 billion in 2012 and is predicted to reach over $20 billion by 2015.[9]

    11.3.14

    RAV4 Rear Brake Pad Replacement


    • http://v.classone.cn/cshow/PBKGVLM3.shtml
    • http://www.youtube.com/watch?v=bMg_j5_AGMg
    • http://www.youtube.com/watch?v=Mmls5foCor0
    • http://www.youtube.com/watch?v=OjrY7G8o99U
    • http://www.youtube.com/watch?v=VxLTDtaRCZk
    • http://www.rav4world.com/forums/99-4-3-mechanical/105618-replacing-rear-brake-pads.html
    • http://www.rav4world.com/forums/96-4-3-general/83979-replacing-back-brake-pads.html

    7.3.14

    CMDB

    http://en.wikipedia.org/wiki/Configuration_management_database

    configuration management database (CMDB) is a repository that acts as a data warehouse for information technology (IT) organizations. Its contents are intended to hold a collection of IT assets that are commonly referred to as Configuration Items (CIs), as well as descriptive relationships between such assets. When populated, the repository becomes a means of understanding how critical assets such asinformation systems are composed, what their upstream sources or dependencies are, and what their downstream targets are.[1]
    CMDBs are used to keep track of the state of different things that are normally referred to as assets, such as products, systems, software, facilities, and people as they exist at specific points in time. The maintenance of such state related information allows for things like the reconstruction of such assets, at any point in their existence, as well as for things such as impact analysis, in the cases of root cause analysis or change management.
    The IBM ITSM framework describes the use of the CMDB as it is tied to software development and all aspects of an information system as it moves through the Systems development life-cycle.[2]
    The Information Technology Infrastructure Library framework, also known as ITIL describes the use of CMDBs as part of infrastructure operations and support. In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment.
    A CMDB helps an organization understand the relationships between the components of a system and track their configurations. The CMDB is a fundamental component of the ITIL framework's Configuration Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB from other sources, such as Asset Management, in such a way that the source of the data retains control of the data. Federation is usually distinguished from ETL (extract, transform, load) solutions in which data is copied into the CMDB.
    The CMDB records configuration items (CI) and details about the important attributes and relationships between CIs. Configuration managers usually describe CIs using three configurable attributes:
    1. Technical
    2. Ownership
    3. Relationship
    A key success factor in implementing a CMDB is the ability to automatically discover information about the CIs (auto-discovery) and track changes as they happen.
    CMDBs contain metadata, and thus the concept overlaps with that of a metadata repository which are both used in running large IT organizations. Configuration management addresses how the data is to be kept up to date, which has historically been a weakness of metadata repositories.

    Single Pane of Glass


    • http://managedview.emc.com/2012/04/a-new-way-of-thinking-about-a-single-pane-of-glass/

    Building an ad-hoc Reporting Application with Ext JS and Couchbase: Out ...

    6.3.14

    NodeJS + ExtJS


    • http://cwbuecheler.com/web/tutorials/2013/node-express-mongo/
    • http://www.alsonkemp.com/geekery/extjs-4-models-node-js/
    • http://devjs.eu/en/ext-js-4-app-with-expressjs-nodejs-and-mongodb-on-the-backend/
    • http://www.ibm.com/developerworks/cn/java/j-nodejs/

    26.2.14

    The Trick of Software Development

    How many people would claim they know how to build successful software? I doubt there are many, although I am sure there are many people can help improving part of the system, identifying performance bottlenecks, and reducing memory footprints. But building software from scratch? It is way too difficult.

    Why? Simply because this is the way software is built. To be more specific, there are two reasons for that:

    Firstly, software is built by people mentally, instead of physically. There are many other things are built mentally, such as paintings, poems, and music. However, look at all those other things, how many are built by group of people? And how many of them need to be "useful"? For software, it need to build by group of people, and it need to be useful.

    Secondary, software system are based on a rapidly changing industry, which is the silicon industry. The Moore's Law is the destiny of software engineering, and where the miserable comes from. One day a friend of mime argued with me why software engineering couldn't work as civil engineering. I asked him to imagine if the material used for constructions became 50% lighter in 18 months, 50% thinner in 18 months, what would happen in this industry. Then he got my point. And yes, this is where the problems come from. The whole industry of software engineering essentially dynamic. I really don't think that Product managers know what software we should be, and I would doubt any software architect know how to build a piece of software. Basically, software engineering doesn't work top-down. With less experience for lower level of engineers, it can't be bottom-up either. So how to build our software? To make things even worse, I don't think our customers know what software they need.

    So basically, we are at an industry that no one knows how to build the products, and no way to build the product right. We are screwed from beginning, like it or not.

    The only way to build a software product, in my opinion, is to just-build-it. Really? Let me talk about it a little bit more.

    I would like to define some kind of distances for software development. For example, the distance of test cycle, the distance of feature development cycle. These two are the most significant ones of them. So Unit Test are so important, because we reduce the distance of test cycle into some sub-second ones. But for feature development cycle, let's talk about some "normal" way.

    In some teams, if it is not most teams, we have Product Managers to "collect" a list of features for the development teams. Whether or not being Agile, the features will be pushed down to the development team, and the team try their best to develop them or feedback to the Product managers, or the POs. Most of time there are some back-and-forth processes until we settle down, and there come our features.

    In this way, I saw some teams who develop some simple feature in half a year, while those features could be implemented some other ways in several days. The communication between engineers and Product managers are so expensive, not to mention there are other communication costs between engineers. 

    The first Agile manifesto is: individuals and iterations over processes and tools. 

    But what does it mean? Different people have different view though. My experience tells me that we need to encourage our engineers to help finding the right features we really want to build, not having them just simply top-down. For the POs, they simply need to understand what those features are, and how they could be useful to the customers, and prepare to explain to the customers that why it doesn't work in the way the customers are thinking about.

    This is how Google is doing I guess, according to the book "How Google Tests Software". And I truly believed this because I found out many good features in my products were from those short distance of development. 

    There are many other tricks in software development. The rule of thumb is being Agile, which I truly believe in. But Agility is not just a word, we need to make it real.