- 今日推薦開源項目：《自然語言處理課程 nlp_course》
- 今日推薦英文原文：《「Your app will be finished on Tuesday.」 — which Tuesday?!》
今日推薦開源項目：《自然語言處理課程 nlp_course》
推薦理由：一個按周進行教學的自然語言處理課程，課程內容包含講座和研討會，以及課程作業和相關的文章，如果對自然語言處理感興趣的話可以來嘗試著學習一下，講座和研討會的內容都是以視頻的形式提供的，所以可能會需要一點英語基礎，在嘗試之前也不要忘了根據它的要求安裝所需要的庫。
今日推薦英文原文：《「Your app will be finished on Tuesday.」 — which Tuesday?!》作者：Tomer Dicturel
原文鏈接：https://medium.com/swlh/your-app-will-be-finished-on-tuesday-which-tuesday-bffaa90d20ca
推薦理由：軟體開發計劃失敗的十個原因，避開它們吧
「Your app will be finished on Tuesday.」 — which Tuesday?!
If you search online for trends in software development you』ll find an endless supply of information on booming technologies and how tech is going to impact every sector by 2020. We hear about all the amazing changes new technology will have ad nauseam, but I』m here to question the latter part of the previous sentence. 「By 2020」. For those of you who don』t speak 「software engineer」, that means 2040. As the only guy at Crane.ai that doesn』t write code, I』ve been plagued by this problem for the longest time. Of course, non-coders are also part of the problem; this post was originally going to be about 5 reasons why software development projects fail, but in full client fashion I changed the spec halfway through the project and so it』ll now be about 10 reasons why software development projects fail.
1. Poorly defined (or, god willing, undefined!) outcome
「Mobile app? We built a bridge, does that work?」
One of the largest problems plaguing software development projects is a poorly defined outcome. Without proper definition as to what the 「end product」 should be, a project is guaranteed to fail. This is so vital that it could quite possibly change the direction of the project itself (which is why it』s #1 on my list!). I highly recommend building a specification sheet to better identify what the product will look like, what it will do, and how it will do it. More on this under communication and expectations!
2. Solving the wrong problem.
「We built a new wooden bridge that looks way prettier than the old one. Cars? Oh, no, it can』t support cars. Pretty much anything heavier than a bird will break it.」
Another common issue is solving the wrong problem. This lies along the same lines as a poorly defined outcome, yet is much broader in scope. Although you can properly identify your end product and solve the other issues discussed here, if your solution does not properly address the problem then you』ve gotten nowhere with the project.
One way to solve this is to incrementally ideate. Identify your core problem, what steps could be taken to solve it, and a possible solution. Next, constantly iterate the product through with your end user — maintain a constant review process to ensure the project is properly addressing the needs of your user, and remains a solution to your core problem.
3. Not enough communication.
「We built half a bridge, they built half a tunnel.」
Coming in at #3 is the core problem plaguing virtually every project, industry, and business — communication. Communication is vital at every level of a software development project. At an internal level, your developers need to communicate effectively to ensure they build tools and pipelines that in coordination and are properly compatible. A common solution here is to draft specifications beforehand for design, APIs, and any other engineering required in your project. This is vital to saving hundreds of hours of time that could otherwise be wasted in refactoring and restructuring. At a higher level, it』s also important to properly communicate with other teams. The marketing team, for example, needs to know what is technologically feasible before selling the concept.
Failure to communicate at this level can cause project-shattering issues; the product could end up being severely detached from what was sold, promised, built and needed.
4. No plan or timeline.
「Yeah… it』ll get done around like… maybe a couple weeks? Not sure what we』re gonna do after that…」
Regardless of whether timelines and plans are adhered to, it』s important to have one. It provides your project with a sense of structure and gives you an estimate as to when and how tasks will be completed.
Of course, a good plan reaches much further. A good plan or timeline can also serve as a common border for large teams, allowing them to operate quickly and efficiently in sprints. If a feature falls through or needs more time, then the plan/timeline can be adjusted quickly, and the budget adjusted accordingly.5. Lack of accountability.
「The buck stops… over there, bye!」 — Harry Truman, probably
When shit hits the fan, someone has to be ready with a mop. If a feature falls through, it should be clear who is accountable and what steps should be taken to prevent this in the future.
It sounds childish but a common occurrence in the software development industry is 「pointing fingers.」 The backend engineers will blame the frontend engineers will blame the sales team will blame the marketing team will blame the legal office will blame the management will blame… This process is not only time consuming and disastrous for morale, but it leaves the core question — 「what went wrong?」 — open and unanswered.6. Moving the goalposts too often.
*「Ok, but now the bridge needs to also act as a runway, have 10 more lanes, and how about a park in the middle of it?」
* It』s important to keep track of a project』s goals and make sure they are met in a timely fashion. While it is possible that a project needs to be expanded or the requirements have changed, making frequent modifications to the 「end goal」 can not only devastate morale, but make a project outright impossible. Often times, changes are unplanned and require extensive refactoring; over time, this leads to a large amount of wasted time, and eventually a failed project.
What may seem like a small change at first could end up becoming a long-term development project.7. Inadequate documentation and tracking.
「The instructions to defuse this bomb say to pull the red wire once the power cuts off, but all of the wires are red and the power was supposed to be cut 10 minutes ago!」 — James Bond, at what will be the end of his career
It』s great to follow an agile methodology and move fast, but documentation is always important. Undocumented code can lead to years of technical debt and can cause tremendous issues down the road — 「what does this function do?」
It』s equally important to document the product. Every step of the process from ideation to design to execution should be well-documented to ensure that the project is easily navigable for others and stays on track. Good documentation can allow for easier project tracking — in an agile system, try a kanban board or similar to keep track of tasks!8. Badly defined system requirements.
「WTF do you mean there』s only 5 loaves and 2 fish for all 5000 of us?!」
The technical requirements of a project can be hard to gauge, but it is extremely vital that you do so. What may seem like a small extra addition may turn into a turducken of an issue, involving allocating additional infrastructure and redefining the entire system to introduce support.9. Poor preparation.
「We』re still flying half a ship.」
Often times a project is exciting and easy to jump into; however, it is vital to its success for the proper preparation to take place. Specifications need to be created, designs must be drafted, a timeline should be agreed on, and resources should be allocated.
A popular method of managing this at a technical level is Test Driven Development. Before writing a single line of code towards a project, plan out the architecture and what each piece needs to accomplish. Next, write tests to assert that each piece actually does what was intended. In this manner, you have a framework ready with set goals and can quantify progress on the development of your product.10. Unrealistic expectations.
「Ok, the app looks good — but why doesn』t the color scheme automatically change to match the user』s phone case?」
It』s important to manage expectations. Often times, the client asks for a feature that is unreasonable, impractical, or flat-out impossible. A common practice is to limit the number of changes that can be made to a spec and to have an engineer present during discussions to determine if the proposed feature is technologically feasible.
Hopefully, by avoiding these 10 pitfalls, your next software development project will be an astounding success! What issues have you run into in your software projects?
