Modern testing for modern stacks

We have gotten into the habit of thinking deeper about one topic on a weekly basis. We pick topics based on anything interesting we read - so the topics can range from 'how to express the value of testing' to 'Dieter Rams' design principles' to 'effective remote work habits'. Employees are guided to spend no more than one hour researching the topic online. The emphasis is on coming up with their own ideas and interpretations. We then meet as a group to exchange ideas. I love this habit and consider it one of the more unique benefits you will enjoy at Qxf2.

Topic: The laws of software engineering

3-Nov-2016

This talk addresses a familiar problem in our niche market of startups: engineering and business believe in different laws of making software. You'll notice a lot of quality problems arise from this fundamental problem of different perception. As the lead or only QA at a startup, you will need to be able to tactfully articulate quite a lot of the points made here...

Our thoughts

Arun

There are several good insights in this talk and it hit close to him. I liked several points. I really liked the summary slides @ 12:36, 33:37, 44:30 and 57:00. The points under the executive's job are also laid out well. I want to emphasize the third law - software bits are not the product. Same for our market - automation and test cases are not our service! Also worth noting is the pie chart of failure modes (39:30). Look at how many of them are not because of bugs. I also hope whoever is going to work on our productized fixed time offering took notice of the basic/expanded/advanced table. Aside: I found the presentation style hard to follow in that he put up the 'ugly facts' and stories before his executive summary/laws/conclusions.

Avinash

Actually a very good article which gives a very broader picture. I like his way of putting things with stories. I could related to lot of things and got some good information regarding how much actually is spent on engineers and Marketing guys. As someone from the development team we don't consider that a product has a lot of different aspects associated with it other than our work. We need to look at the product as a whole. The marketing and sales guys play a very important role as well. Prioritization is important even when we test we need to be able to figure our whats the most important task which has to be done. As a company i guess we spend lot more on R&D. The framework we build was a product of it. Now its easier for us to start automation within couple of days because of it. We may have spent on R&D but now we can make profit out of it. Coming up with a strategy is important but its very tough too. Lot of bigger companies have failed.

Annapoorani

It's a fact that no company will have enough developers. we will always be in a place where there's more stuff in the backlog, there's more stuff on the roadmap,there are more things from customers and everybody else that we can possibly build.What we need to really work on in prioritizing the task that we have and delegate accordingly to the developers.we also need to look at what is the priority for the business,the customers and the revenue that will bring to the business.Then we need to ensure the product is built to cater to all the customers.The author has quoted the classic example of one or two people buying our product is more disaster than nobody buying it,because he will spend more time in maintaining the product ,the customers who have bought it.

Smitha

It's a hard article to understand & I can't relate to my past work experience as it focuses more on software in startups. I agree to a few things that he has said ie. we should have some point of view on where the market is going. Its ok to be wrong and to change your mind, you need to have a vision of where we are going too. This bit I can relate to my work with clients in Qxf2 as there maybe several tasks but its upto us as an engineer to prioritize as everything can't be done. You need to build something which will solve the problem and report the bad things too so that they are aware of it.

Rohan D

It's practical article written by Rich Mironov. He spends almost equal time in both Engineering and sale & marketing department. So he knows everything about thought process & practical constraints of engineers and managers. I like the way, he explained about thinking of engineers & management people. Magical thinking comes from AND point of view. Do everything you are doing and this one more add to things. Development works from Exclusive OR point of view. To do feature A, you have to not do feature B. I am agreeing with his statement, Development can never built as fast as we can dream. In his first law, he want to say, if you add more things to the queue, the less productive your team becomes. Development process cost of software is fixed. Goal is to find identical or rear identical customers, so we can sell the same software more than once. I agree from his explanation, software bits are not the whole product. He ranked reasons for failure of software and only last two are engineer failure and rest are whole product failure. Most of success/failure of a product is determined before they pick first developer.

Shiva

This topic was really informative. Development teams are always one man short. You have to be 80% busy to get the things done. As an executive here you may have to make trade-offs and battle magical thinking. Before you build a product you would want a customer group that would need it. Do some research and check there is a market for it before you work. As an executive you have to focus on segments and not deals. Hold back the tide for one special customer. Companies fail because they build the wrong thing. Beware of Mean time to joy. Executives should think about what your paying people for. Are we paying them for customer joy and retention or output. You need to have a clear idea of how the future would be for the industry you are involved in.

Indira

The author Rich Mironov has very nicely explained the four laws of software economics. i have got good insights on some of the things mentioned here.He clearly explained about how development teams, management/executive teams, marketing teams are all important for product success. In the first law he rightly mentioned that overloading development team and keeping them 100% busy does not mean that they are delivering 100% results. The author feels that, instead of dumping all the work at a time we can actually achieve good results when we try to figure out the most important things and getting those things done at right time.I liked the way he explained about revenue generation and how companies spend on R&D which i can relate to my previous where the company used to spend about 12% on R&D. In the second law "build once and sell Many" the author feels that before building or engineering any product understanding the pulse of the customers/user groups is very important and checking if there is a market for that product or software. He explained this by giving a example of "Amazon fire phone" where amazon launched this product with a certain strategy but that was not understood by many of its customers. In the Third law the author is of the opinion that development is only a bit and is not just enough without proper marketing,planning and a strategy and the focus should be on identifying the customer needs/problem before building the product instead of building the product and finding the market for it.

Viraj

I found this article to be very informative and helpful to understand what happens in the Software industries. The author(Rich Mironov) puts 4 laws here that any company should follow in software industry. 1) Going through the first law, He(author) brings us to the point "Your development team will never be big enough." , Its hard to find good developers and - developers are human - This means development can never be as fast as we can dream. The developers are often made irritated with magical thinking -"My neighbours child can do that 10 lines of code in an hour" - That really doesn't work. The author says us here "If you over load team, they will build less" . As an executive - Make hard trade offs, Battle magical thinking :) . 2) In the second law he talks about sales and marketing with law - "Law of build Once, Sell Many." .He says here, All the profits are in the nth copy of product build. That means developers cost per hour increases in some proportionality - say x, and all actions related to product in parallel goes x times. And this brings us to the point, Cut the costs - wherever possible. But this is not the way, he insists "Goal of software company is not to minimise the costs but to maximise revenue ". Building a product in different type like - pro, advanced should have the features that makes really difference between product type. It shall not happen that Advanced is having only 2-3 more feature than Pro , Or Pro is useless until advanced is purchased. It comes to the product development team with sense of whats we are building? , Why? and Who's gonna use it? Is there requirement ? ("There's nothing more wasteful than brilliantly engineering a product that doesn't sell "- we can think for FirePhone). This comes to the executives role as - Strategic are of choosing customers who want the same solution., Focus on segments - not deals. 3) The 3rd law as "Law of whole product ". Here, the author talks about product and how sales and marketing should be done. He asks for deep customer analysis. Not to sell naked product.(Product without any information, packaging etc). 4) Here he talks about Emotional approach towards the customers. As a law "You cant outsource your strategy" - All about "Kano model" . It is important that how customer feel about the product - far more important than what product can do? . People like to feel, like to feel controlling something.(Most of the people like to hangout with their Dog than their loved ones, Strange ! why?- Because of John calls Billy to come here fast, Billy says 'Just a min, Let me finish this Pizza', But if a dog-'Bowwww Boww, I am here Sir!' --That mentally satisfies John) . Like that two broad questions for your product - Does it satisfy you?(Yes/No).....is it up to the mark?(Yes/No).

RohanJ

It was a wonderful talk by Rich Mironov who has been known as a Product Guy. In his talk he speaks about 4 laws of software economics from which i have experienced the first 2 laws in my previous startup i was working in the first law he speaks about Prioritization, In my previous company we had DIY Support team which used get feature requests from clients to the developers, they used to argue about it and i remember them saying that its just 10-15 lines of codes which u have to write and the developer used to get irritated with it. So then we decided prioritizing the feature requests on the basis of Business demand & Technical Feasibility. In the second law he speaks about Segmentation for Pricing Plans .I think for every SAAS based startup it is necessary to carefully find out which of their features stand out from their competitors for which the clients will pay and will be easy to attract new clients. One more thing I liked from the talk is that software bits are not the product.

Raj

In this article the author Rich Mironov has Explained about 4 laws of Software economics. He not only dealing with Software side he also has an experience in the Marketing field. In the Law of prioritization he suggests that an 85% busy team gets more work done than a 100% busy team and 110% busy team .It's that by making the important works done at the right time rather than doing unimportant works. And even he suggest the Law of build once and sell many, It means that the product must be familiar and good enough to maximize the company revenue with minimizing the development cost. It is completely dependent on the product quality as well as the marketing strategy and sales team. The Marketing team must help the customer how to use and maintain the product.

paper cut