Ropewalking Methodology: from software development history to encourage none-technical person to code

In the May/2018, somebody wrote an article of Meteo Fall software development. Obviously, it was a software developer in Japan made an ironic remarks on his situation. However, sometimes engineers will use even more sarcastic way to describe his job or to address his environment didn’t really fit his expectation. But this article will tell you a different story of my colleague M who is not CS background but invent a development methodology.

Software development methods gradually evolved. The earliest records we could find is SDLC (Software development Life Cycle) during 1960 to 1970. However, all the history record of SDLC are 3rd hands. Latter after 1980, UK government regular SSADM to be officially used in government project.

In pre-internet age, waterfall, prototyping and Spiral are all fine for software projects. At that moment, software projects were all pretty much very huge. Most of the development tool were expensive, the diversity of computer is limited in certain area. But still, Boehm’s Spiral methodology already show the concept of interation/sprint.

Then, the first web site (1991) born in CERN; first “easy” Unix-like OS Linux introduced at 1991 ;first “cheap none-tech operation system” Win95 came out in 1995, along with all other things….these internet-ready stuff impacted the world and of course created the diversity of engineer’s type. The critical reason is software engineers could easily learn skills from each other in very low cost (www) and very short of time.

Soon after that, all kind of principles, methodologies, genres, sects ran out for fighting which one would be besting fit within a software development team…

Now, engineers could have more than 10 different methodologies: Scrum, DSDM, Kanban, BDD, UP, Lean, ExtremeProgramming, Chaos Model , ASD, Crystal Method, FFD, Slow Programming[1]

We surely could invent more methods in the future. And actually, I’ve seen one talented colleague (lets call him M) made another approach in past few weeks, we named it together: Ropewalking Methodology.

WARNING: do not try Ropewalking Methodology at your engineer job. TRYING THESE TRICKS COULD LEAD TO BE FIRED.

Ropewalking Methodology is easy to learn and pretty much easy to adopt. The life cycle is:

(1) decide your amazing goal: for example build an AI chatbot on LINE

(2) write whatever code to make this target happen, along with the necessary environment setup (ex: AWS, LINE developer console)

(3) just run everything and if didn’t run correctly, try to fix somewhere you can guess

As engineer, you might probably say “What the hell are you talking about?” But M did make that methodology worked for a few times to make his own project working as expected. Most of the time, he was just like the falling of failure ropewalking. As his colleague and his own audience, I am pretty excited to see how he walk (code) which is an entertaining behavior to me :). Not because his code is good but I somehow expected his falling: run with fatal error XD. Just like people watching ropewalking, we don’t want that guy injured but sometime we expect a fall. I am sure that why if that thing really works, I will always see a extremely satisfied smile on his face.

To be honest, this is not a good way to deal with a software project. However, M is not an engineer with CS background. He is very young and this is his first few months after graduate from university. The reason why he try to do programming is that he want to make his own work better and hope to reduce human-error inside his team. Meaning, he really want to make his work better and he understood that software technology could be the way. He no need to do that but he try his best to learn and work on that. He did have courage to learn things which he didn’t know, he did have courage to take action even he has less skills in software development but this is not an excuse. Of course he knew that it is also important to learn from others so that I could have a chance to help him a little bit.

M is not in ShopBack’s engineer team, he is also not involved in any engineer tasks. However, in the future I believe he will be better than the one who just complain of his own environment by wrote a sarcastic article. In ShopBack, we expected our colleague just like M, didn’t complain the difficult he faced but try to break/change the environment even it is as hard as walking on the rope. It is my honor to help a bit of his task and I am pretty sure he got the talent and potential to join a software engineer team in the future.