Modern testing for modern stacks

"Keep it small. Keep it simple. Let it happen." I really liked this phrase in the post. We would have heard most of the sportsman also say these keep it simple and let it happen, but it harder to implement it always. Initially in most of the companies things would be simple as very less people are involved, however as more people and system gets introducted things becomes complicated. What I feel is it takes lot of planning to keep things simple too. Once we start making more rules and process things starts getting complicated as priorities also changes. Like in case we have lot of process in testing like document all the tests, keep all details when excuting, have complicated reports the focus shifts gradually from actual testing to adhering to process. Ideally have very less process to make things simple and let it happen

In our work environment, its important to have space for creativity. We shouldnt make the rules and processes too complicated leaving no room to think creatively and come up with an emergent solutions. There should be opportunities for more interactions and relationships in the work environment. Things should be simple and small because complex rules lead to complications and dont encourage people to be innovative.

It a thinking article, which made me agree that lesser the rules the better. Emergent means things that become visible or known. You might have a tight process and follow it too but sometimes unknown things do crop up. So let it be, give them a chance to become visible, we'll try and resolve it later. There are some practices which eleminate the emergent behaviour. I agree that this restricts the creativity. I would consider this - If you have written a code, then it might have some short comings, let it be. Lets see how it works and then give way for some creativity and write better. Have the basics offcourse though. Another example that I thought was the internship interview process, we had everything set right, like how many candidates will come, then how many we'll intake in the forthcoming rounds, but then something else happened which we didnt anticipate. We changed accordingly which gave way to an alternate solution, which was good.

It was a short and sweet article to read.I liked one phrase from this article is that you can't plan for it or schedule it, but you can cultivate an environment where you can let it happen and benefit from it. So I think, that in any organization an individual should be made to put forth his ideas knowing his strengths and weakness. So there should be good interaction among team members which he has very well explained using the birds flocking example.Then he has very well related it to software development process, we should not lock requirements phase before all the problems are well understood.

This article is short and to the point.Emergence made me recall Agile Enviornment in my previous team, Agile methodology worked really well by splitting big task into smaller ones.And even smaller team groups could converse very well.Making things simpler solves the issues faster.Flock of birds is the best example given to work in team and emerge together.

I agree on this point that simple rules lead to interesting behavior and tight rules lead to complex behavior. I relate it to my previous work experience with one of this example. If emergency change request needs to go into production, that leaves the room for dynamic solutions and benefit with user behavior learning out of it . I liked birds flocking example, keeping simple rules like don't run into each other and don't crowd such that they get protected from predators , this example indeed make lot of sense.

I came across this term while reading Getting real by 37 signals. I like the flock of birds example mentioned. The birds in a flock take a path following one after the other and when there is an obstruction in the path it alters the path flexibly following one after another. To achieve this kind of flexibility- to alter path when there is obstructions the size of the team has to be small. Large teams are resistive of any sudden change. An interesting thought that occurred to me is- this dynamism is not confined to tech industries alone. It can be applied to sports. One reservation I have about Agile is that it does not take the fatigue on employees into account.

While developing a software, we tend to go too tight on optimising the code that we leave very little room for emergence. Emergence is something that happens magical when given that space. In case of testing, we shouldn't be drafting our scenarios without exploring the product enough. When we play around the system enough simulating an end user interaction, thats when we can get out emergent test cases that can give an edge to our testing. It helps to see the unforseen side of the product

The article highlights the importance of emergence. In context of software development, complex rules do not make sense. It is not always possible to determine correct requirements, designs, test plans upfront. As we work more on it and gain experience more information will emerge and we can improve based on the iterations.

Its actually accepting the Unforeseen incidents, And how one can accept the incidents elegantly. While we design the code or if we have to test software, we may come across some "Unforeseen Incidents", which, we should be able to understand its complexity and accept the change. We should be able to keep things Simple and Concise, which gives a lot of progress and clarity to our goal.

The author is trying to emphasize on emergence i.e.one of the founding principle of agility using bird flock analogy. Whenever you try to put complex constraints or rules around the system it may give you a monotonous solutions rather than creative solutions. Complexity increases for the user rather than usability. Even simple rules like don't obstruct any other individual creates more advanced behavior or attractive flying patterns in terms of bird flocks flying. Similarly, software created using simple rules may add more values in terms of usability and give you more leeway to enhance it. So the author is trying to highlight that the elegance system often emerges rather than stringently built around the rules. If you try to add more rules/constraints then these systems may not emerge naturally and will not add value to the user.

It is a good article that says about Emergence that is how to keeping the solution simple and small. Also, If we hold the problem very hard then it will be lesser way to think creatively. The better output will come when we think Emergence point of view.

Emergence is an unpredicted occurrence. There was an example of flocking behavior of birds, flock wends and wafts its way gracefully through the sky, reforming around obstacles, and so on. Same way when developing the software, before understanding the requirement/product better if you try to write an optimizing code or writing a complex part of it may deliver an unpredicted result. To understand better, Keep it small. Keep it simple. Let it happen.