I could see why development service team always want to get more and more information about a project. Open it more, then you get better return. Fun reading.
The shittiest project I ever worked on
111–120 of 187 posts
Re: The shittiest project I ever worked on
#112Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. There's nothing that's derailed my projects more consistently when I started out as not understanding the user's needs. They'll never tell you what they want, only what they don't want after you deliver something. I think that's the key difference to an experienced dev/BA. One who can actually sit with…
Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance…
Really great advice, would you mind if I put it up on pastie (obviously with attribution to you) so people can bookmark it?
Re: The shittiest project I ever worked on
#113Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. There's nothing that's derailed my projects more consistently when I started out as not understanding the user's needs. They'll never tell you what they want, only what they don't want after you deliver something. I think that's the key difference to an experienced dev/BA. One who can actually sit with…
The flip side of this is that when stakeholders/customers don't know what they really want or need, you can labor in the "requirements phase" for months. My team spent 900 hours last year just getting a functional spec and high level SRS together for a project that hasn't happened yet. Why hasn't it happened? Because at the end of the 900 hours, we presented our estimate (about 1100hrs) to the customer and he balked at the cost & time. Then my boss bitched at us for spending so much time on requirements in the first place.
Now we're looking at commercial solutions in an attempt to not have to build this thing and deal with this department anymore.
I agree with you 100%, but the number of people astute and experienced enough to quickly and deeply understand the problem to be solved (and the quirks of the customer) are few and far between. In my experience, perhaps 5-10% of any large IT organization fall into this category -- everyone knows who the superstars are and their time is always at a premium. Drives me bonkers.
Re: The shittiest project I ever worked on
#114Earlier quoted context omitted.
Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance…
Really great advice, would you mind if I put it up on pastie (obviously with attribution to you) so people can bookmark it?
Thank you and everyone for the words of encouragement. I've posted it on Medium:
https://medium.com/p/23a07cb0d5ea
Re: The shittiest project I ever worked on
#115Without a pollyfill to support older browsers this is merely a peak into the future.
Re: The shittiest project I ever worked on
#116Earlier quoted context omitted.
"One who can actually sit with the stakeholders and build the system on paper and go through each of the problems as the diagrams connect." Reminds me of an old saying: "If you don't know how to do it, you don't know how to do it on a computer."
heh true, but what about if you were going to use a neural network to do some sort of pattern recognition? You dont know how its done, but the computer does! :D
That's not actually how artificial neural networks in pattern recognition tasks really work.
Once you learn and understand the learning algorithms, you will experience this Wizard of Oz moment, you see how the trick's done and it's not quite as impressive as you hoped. This is confirmed by the fact that it exactly matches the limitations of a typical neural net you've established experimentally.
The tasks that are within these limitations, they perform quite well at, but it's not that hard at all to understand how they are performed. In most cases you can basically run the algorithmic equivalent of a trace debugger on the system. In as far as you can compare it with a brain (but don't do that, it's the wrong analogy--compare it with statistical regression instead), it's one you can take apart entirely, reassemble, run partial components of, tweak, and understand exactly how it works to the instruction level. Plus you can do these things automatically for the most common cases.
In short, there is nothing "magic" about neural networks, or any pattern recognition algorithms.
And to get back on the subject, if you intend to work with machine learning algorithms in a professional/consulting/project setting, probably best to first check the scientific literature to see if anything like this has been done, and what the accuracy/false positives/negatives/ROC curve is that you can expect. Don't expect to beat them, either (you may, but planning to do so by any significant amount is asking for trouble--especially if it turns out it just can't be done). Then, I think it would be clever to first build a "fake" system/interface, without the ML component, limited to just the labeled training examples (if you can't acquire these, give up now[0]), see if the system is actually useful from a software engineering, application and usability perspective, before you actually begin (the fun part) tweaking an ML algorithm, only to later turn out, even if it did its job perfectly, it wouldn't be all that useful in the operating environment in the first place.
This is different if you work for a corporation with a huge research budget, of course. Like Microsoft or Google. But even then, I think that for their ML-enabled end products, similar reasoning like I sketched above is used. Of course the same goes for every type of project that depends on an unknown to-be-researched technology.
[0] yeah yeah unsupervised learning. but if you know what you're doing that well, why are you listening to my advice? :)
Re: The shittiest project I ever worked on
#117Earlier quoted context omitted.
Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance…
Commenting to save this for myself (fellow consultant) -- thanks for the detailed list. :)
Ditto to the first part, commenting to save or myself.
Re: The shittiest project I ever worked on
#118I am working on quite a tedious project right now. It involves 10 years old, quite extensive, Visual Basic 6 programs. No source control was used. In our company it is practice to hire interns for 3-month periods to work on production software. A mix of programming styles can be found in this project. Some functions return 0 when they fail. Others return 1. Or -1. Or False. Or "False". I love it!
Count yourself lucky there was any error handling at all! My current job involves a lot of old (and new) visual basic 6 and there are parts of our software which don't work once you remove the magic line:
On Error Resume Next
Re: The shittiest project I ever worked on
#119Earlier quoted context omitted.
Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance…
Really great advice, would you mind if I put it up on pastie (obviously with attribution to you) so people can bookmark it?
What stops you from bookmarking it on hn?
Re: The shittiest project I ever worked on
#120The shittiest project? Hmm...if he got paid, not sure I'd classify it as such. A waste of time because of business getting in the way of potential efficiency that they perceived they wanted? Yes.
Also, let's not forget that this was 1995 and most big businesses weren't really fully aware of the potential of the internet and the disruption on standard business models that was going to ensue...