TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ego-Driven Development

41 点作者 dmiladinov超过 12 年前

10 条评论

jff超过 12 年前
Sometimes it's not so much "NIH syndrome" as "Everything else really, truly is crap". Scottschulthess mentiones that all CMSes are terrible. Some of my colleagues, for example, needed to spin up hundreds of virtual machines very very quickly, and as it turns out, OpenStack is absolute crap. So they took 2 weeks and wrote something a fraction of the size of OpenStack which can have hundreds of virtual machines running in the time it takes OpenStack to boot up 1/10th as many... and crash.
评论 #4597979 未加载
评论 #4599372 未加载
scottschulthess超过 12 年前
""Not Invented Here" syndrome: Expressed most commonly in a desire for everything needed to be developed in house. E.g.: “Need a CMS? Let’s make our own from scratch!” Perhaps, you work at a place where all your teammates do is constantly bring you bad ideas. Are they really all terrible? Or are only your ideas good enough for the organization? Not Invented Here can also apply to your own head, not just the organization."<p>The answer is yes, they (CMSes) are all terrible. :)<p>"No dedicated QA for externally-facing software: Someone who is experienced at breaking software should have a crack at it before it goes to users. Developers (including me) are too enamored with their own work to really take the time to break it, so someone with a sense of pride in finding problems needs to be given the task."<p>Having dedicated QA is not always good. In fact it is often counter-productive.<p>"Low Joel Test score: The Joel Test remains a great indicator of institutional ego. A team that scores low on the Joel Test does so because someone along the way decided that, "nah, we don't need that here, we are special", and almost certainly they are not. I have yet to hear of a team with a legitimate reason for a low Joel Test score."<p>The joel test is actually quite out of date. Specifically the stuff about fixing bugs before writing features, hallway usability testing, testers, having a 'spec', and having a bug database are all not necessary or good to have in all cases.
评论 #4598018 未加载
评论 #4598034 未加载
评论 #4598588 未加载
评论 #4598548 未加载
fabrizioc1超过 12 年前
There is the other side of "NIH syndrome".<p>In order to "save development time" and implement "best practices" a company decides to use an "out of the shelf" package from a big name vendor (IBM, Oracle, Microsoft, etc) and customize it to their needs. Some initial customization is done and some shortcuts are taken to make the project go live.<p>Fast forward a couple of years. The custom code added by the company complicates upgrade paths and vendor support. The business demands more and more functionality which the package does not support "out of the box".<p>The customization initially implemented turns out to have been technical debt in disguise. They bypassed the recommended usage of the package or platform which resulted in performance problems. Eventually they end up having to re-work everything "the right way" in order to get vendor support or fix the performance problems.<p>This is specially prevalent in corporate IT departments in large corporations.<p>Moral of the story is that "off the shelf" platforms are not a silver bullet. If you don't understand the platform and the business requirements you will have problems later on.<p>I don't know how many times I've fixed performance problems of "off the shelf" packages by simply writing code which replaces the OOB code with a couple of SQL queries/stored procedures and only does what the business needs, bypassing features which the customer does not need in the present.
评论 #4598603 未加载
lmm超过 12 年前
I used to apply the Joel test religiously, but I've gradually come to the opinion that dedicated QA is a net negative. It creates a natural opposition between two halves of what should be the same team, and removes the focus that comes from knowing that what you create will be what's deployed. It also adds friction that goes against the agile "deploy early, deploy often" approach.
评论 #4599064 未加载
评论 #4598163 未加载
bajsejohannes超过 12 年前
&#62; developers and managers repeatedly act as if established best practices do not apply to them<p>... and rightly so. A junior programmer might be better off always following "established best practices", but I expect any developer worth their salt to be able to know <i>when to break the rules</i>.
评论 #4598371 未加载
评论 #4598881 未加载
OldSchool超过 12 年前
Hmm, just playing devil's advocate here but I'll bet that a huge list of successful people topped by the obvious like Gates, Zuckerberg, and even the humble Wozniak have used all of these elements some or most of the time in their development lives :)<p>Generational differences abound and manifest in management trends as people reach an age of influence. Born in the 50/60's - you're more likely to be a lone-wolf type. Born in the 80's/90's and you probably consider teamwork and connectedness to be instinctual. Not claiming either is correct but certainly projects beyond a certain scale can only be completed by a structured team. Too, those who prefer to work alone are not automatically egomaniacs.
评论 #4598319 未加载
zio99超过 12 年前
Add two more to the list:<p>1. No documentation<p>2. Over-engineering<p>I believe EDD affects everyone from the large corps right down to the one and two-person teams. Take a look at highest upvoted hacker ideas here: <a href="http://www.todaystopthing.com/hackerideas/top" rel="nofollow">http://www.todaystopthing.com/hackerideas/top</a><p>They tend to satisfy the "technically challenging" and EDD trap. Now check out the flop ideas: <a href="http://www.todaystopthing.com/hackerideas/flop" rel="nofollow">http://www.todaystopthing.com/hackerideas/flop</a><p>Some of these products exist and are profitable. "Simplifying" a problem/solution doesn't make it any less of a project worth pursuing. Great read +1.
mbustamante超过 12 年前
every software company in the US is using pair programming ? is that wrong not having pair programming ?
评论 #4597843 未加载
评论 #4597856 未加载
chicceo超过 12 年前
This is a great article. I have never heard of this, but it's so true - thanks for the insight.
julianduque超过 12 年前
Hmm, I can tell I work for a company that do that. Thats sad :(