Software Development Project case study-hazards of Complexity

First, let's start with A story. Company A undertakes A project of customer K, wants to build A financial software, first develops the WinForm end, and then Implements similar functions by referring to Winform on the web end. In order to maintain the conceptual integrity and consistency of the product, and the end Users (Users) do not need to change their usage habits, the customer requires the web end to be the same as the Winform end.

 

One requirement in the system is to create A wizard. After the Web developers of Company A finish the page, they find that some bugs cannot be debugged, And the whole page is very slow. After seeking help from senior developers of Company A, the investigation found that this page carries too many nested controls and there are too many business logics. The result is that the page is very complex, as a result, there are thousands of lines of related code, which are difficult to maintain each other. Therefore, many inexplicable bugs have emerged, and the performance of the entire page has become particularly slow.

 

Company A had to advise customer K to split the page, but customer K had to pay A lot of extra time and cost for it, which was out of the expectation of customer K, in the end, it caused a lot of unhappiness for customer K and a lot of negotiations.

 

What can we learn from this story? What's wrong?

 

1
-
A requirement that is too complex and too large should be avoided. On the one hand, it increases the overhead of implementation and maintenance, and on the other hand, it will increase the end user's understanding and learning costs; therefore, simplifying requirements is crucial for a successful product. This is also the value of the product manager. In this case, there is clearly a lack of good product planning. If there is no clear product manager in the team for various reasons to be responsible for product conception and design, in general, this work will be apportioned to every developer, because they must decide what the page layout looks like and how to interact with the end user. In general, developers lack experience in product design, so the result of such decentralization is generally-the lack of consistency of products, and the complex and chaotic interaction of associated functions. Therefore, the first lesson is that we must have a unified process of well planning and designing the product (whether the product manager is responsible or several people can discuss it together ), in addition, product features must be simplified to avoid complexity.

 

2
-Under the existing technical conditions, it is still very difficult to achieve the same effect as winform on the Web end. Although this idea can be understood, but in practice, many trade-offs and functional simplification are required. The idea of "Implementing Web Based on winform" seems simple and easy to use, but in fact it is highly risky. Similar to this case, it is recommended that the Web end be considered and designed in parallel independently of the winform end, and be streamlined as necessary. Of course, consistency with winform is one of the important considerations when you plan the Web end independently.

 

3-
Do it right according to the customer's requirements, but be sure to add your own thinking and judgment. At the beginning of implementation, developers undertaking tasks fully assess the risks brought about by PAGE complexity and fully communicate this risk with customers, which may be avoided, after at least full communication, the customer will not pay the order at all, which avoids many unnecessary disputes in the future.

 

This is an actual case and I will share it with you. There are still many software project development cases that you have experienced, seen, heard, and discussed with your friends. You will be able to share your stories with us in the future.