8 ms·

Although 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

Although 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 stakeholders and build the system on paper and go through each of the problems as the diagrams connect. What you end up with is the stated requirements (tip) and the unstated assumptions (iceberg). These types of projects are easily spotted as they're often called "quick" or "easy", which in layman's means no one's really thought about it yet.

greenyoda 13y ago
"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."
- chii 13y ago
  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
  - pgeorgi 13y ago
    now you have two problems... (because the NN will probably fail at the most inopportune moment and you have no idea to fix either the NN or your actual project)
  - rwallace 13y ago
    Then well and good, but alas situations where that will work and deliver business value are rare enough you can easily spend a lifetime as a professional programmer without encountering one.
  - tripzilch 13y ago
    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? :)
    - didyousaymeow 13y ago
      I have an upcoming project where we'll be implementing a pattern recognition algorithm - think smart flash cards. I've read up some on timed-repetition and a small amount on how neural networks work. With your experiences, do you have any recommended reading that would help me with the neural network learning curve?
- willvarfar 13y ago
  Test-Driven Sudoku? :)
- huherto 13y ago
  Paraphrasing: "You don't know how to do something until you can write a program to do it"
grumps 13y ago
Oh yes the "easy" project... we just need... The real issue is sales...you make the sale because you have to. Then you stick the project on some poor PM/Ba/Dev who will fight with them forever over this stuff. Maybe I'm just bitter about the situation that I continually get stuck in.
- hef19898 13y ago
  Boy, do I feel with you. But look on the bright side of it, we are not alone, are we? ;-)
  - grumps 13y ago
    Yea there are times when I think gee "I'm so happy to be above the ground and vertical." Then I get an irritating email and well that thought flees.
- n1ghtmare_ 13y ago
  Amen, brother :) !
misterjangles 13y ago
The tricky part is often convincing a client that pre-planning is a necessary part if the process and, though it is billable time, will ultimately save money. Many client don't appreciate that programming is not just writing code. Also you can wind up meeting and planning yourself right out of a gig sometimes - which is fine if the gig wasn't truly necessary. But can be bad for your business if you spend hundreds of hours doing this for no compensation. This is a real situation that happens - you get a client that wants a big project and after many meeting and calls you determine that a Wordpress install will suit them perfectly. Their network guy does the install and for all the money you saved them your reward is that you don't get the gig!
- nostrademons 13y ago
  If you're billing time & materials (which might be a good idea for a contract of indefinite scope), you'd still get paid for the time spent doing due diligence. You might even be able to sell a time & materials contract on the basis that it gives you an incentive to point out simpler solutions that require less maintenance even if they involve using competing off-the-shelf products.
  - misterjangles 13y ago
    Exactly. Good clients will understand "hey, this guy just saved us $150k". Bad clients will think "I just paid a programmer to do nothing!" Learning to recognize and get rid of those bad clients (or convert them into good clients) is a skill that can take a while to learn.
    - hackula1 13y ago
      Along the lines of: "I paid my attorney $10k and I didn't even get to court!"
- brianmcconnell 13y ago
  The trick then is to get clients who know they just want to "have it taken care of", and have much higher billing suppliers (IP lawyers, pharma experts, etc). In that case, they don't really think twice about paying for process in advance of coding. Pharma is a good example. Being a contract resource for a software company, where management tends to think everything related to software/IT is "easy", is a guaranteed shitty project. They'll second guess and micromanage everything you do. And then when they burn through their OPM, they'll screw you.
perfunctory 13y ago
> Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. If everybody was so picky the size of the IT industry would diminish by 90%.
- lifeisstillgood 13y ago
  and the success rate? and value delivered?
  - weland 13y ago
    How dare you bring technical excellence as an argument? Don't you know this is about money, not performance? Jeez, get an MBA.
    - lifeisstillgood 13y ago
      that took a minute to process ! cheers
shailesh 13y ago
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 guys to create a coherent road map for the system to be built. What tends to happen in practice is a combination of chance, human errors and conflicts in priorities. To survive, we must understand ourselves as consultants, the terrain and the opposing forces (anything that prevents money getting deposited in the bank). Consulting is a business => the individual consultant must shoulder quite a lot on himself: * Advertising himself * Finding work * Meeting prospective customers * Writing proposals * Closing the deal * Writing a contract * Defining the scope of work * Nailing what is to be done and what is to be avoided * Constructing components of software * (In worst cases) baby-sitting customer's devs / ops * Testing his modules * Getting money in his account So, when we talk with customers, there is inherent pressure in closing the deal versus precisely defining everything. Icing on the cake: back of the mind, you might worry about milkman's bills and the birthday gifts to be brought for your kid's friends. Always have a good runway: six months seems optimum. Technically, even three months should suffice, but it is insufficient for the edge case when these three things hold true simultaneously: * You've to walk away from a customer in the middle of a project, and * Dry sales pipeline, and * Unexpected crisis at the personal front: very close friend in need of money for surgery etc. God be with you. Now, back to the main track. The key is to first understand the priorities of stakeholders. The contradictions are easier to grasp once we put ourselves in the individual's shoes: * [Convenience] The users want everything including the kitchen sink, * [Accountability for the risk] They want it yesterday but won't commit to it on paper since you're in early sales stage, * [Cost] The finance folks want stability and the most economical price, * [Availability] The decision maker prefers to spend the least of her time to be spent on this activity, except when it's her pet project. These roles may be played by different people or the same person. Again, we don't have to agree, but acknowledge that things are meant to be imperfect. Most people are actually decent and rational. Now, somehow, the consultant must figure out a good path. To begin, he should have a good handle on: * The industry in which the customer operates, e.g. BFSI, Energy, online marketplaces, food, fashion etc. * The nature of the market: oligopoly, crowded, emerging et al. * The level of Govt. regulation: HIPAA? PCI? * The customer's position: among top tier, mid-size, small firms. * Customer's customers: helps to track the wind. * Standard pain areas in the market. * How customer's competition and partners survive the pain, specifically the differences among the customer's approach and the competitor's ones. * The financial health of the customer: if possible, try to talk with their existing suppliers in other arenas (e.g. the guy who supplies printer cartridges, the cleaning lady etc.). Based on that, assuming we've landed a hot lead, say that we want to convert it to money. There will be a lot of conversations over the phone, e-mail, chats, face to face; what is to be left out of those conversations is really context sensitive. The important parts are: * What problem we're going to solve for all stakeholders? * How we're going to solve it? * Communicating our approach and progress on a timely basis. * Improving Vulcan skills: like money, expression of anger is a great servant but a terrible master. I leave out the details on the development process, since it depends on the individual. Here are a few things which worked for me marvellously in certain contexts and doomed in others: * Setting expectations by explaining the cone of uncertainty in the estimation process. Always be prepared for some customers, who deliberately mislead you that they don't understand the mumbo-jumbo, projecting ignorance as a shield so that they can ruin you on payments. Mostly you should refuse such customers, unless you're in an extreme crisis on multiple fronts. * Writing use cases for the modules / systems I was supposed to work. Most customers say that they don't want any time spent on "documentation," to which I reply that writing a document is not "typing" but "nailing the thoughts to deliver higher quality work." * Creating mock ups using sketching tools (even Excel/LibreOffice can be good enough, if one is pressed too much for time) in the absence of UX designers on the team. * Writing test cases before writing my code. Helps to ease the integration. * Optimizing lazily: progressively refining the artefact (document / mock up / test / code). * Knowing the expected value of each task: (amount of money * satisfaction * improvement in reputation) / (e-mail tennis * stakeholder's understanding of requirements * payment latency * time spent) Finally, reducing it to just one sentence: be nice, believe in yourself and humanity, be multi-dimensional and please heed Guy Kawasaki's advice about reading voraciously and omnivorously. Edit: formatting.
eitally 13y ago
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. <8 months pass> 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.
- hef19898 13y ago
  Try to keep your spirit up despite all this, especially your team. Things like that were part of the reason why I quit my last job. Completely true is the thing with the superstars. I knew one myself, a genius in warehouse management systems. If I had him on a project, it went smoothly as anything. if I didn't I stayed in development hell for months. But seeing this guys workload, he wasn't off any better. But in retrospect, the general direction the organisation took at my last employer wasn't that bad. Execution lacked, so.
- cygwin98 13y ago
  If you billed those 900 hours for doing RFP for the customer, it doesn't sound too bad.
  - eitally 13y ago
    We couldn't bill them -- it was another SG&A department and we (IT) don't bill them for our work.
    - roel_v 13y ago
Agathos 13y ago
> Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. The formation of this sentence seems odd to me. Why can't we say it's a fun read because it's a classic example etc.?

greenyoda 13y ago

"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."

chii 13y ago
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
- pgeorgi 13y ago
  now you have two problems... (because the NN will probably fail at the most inopportune moment and you have no idea to fix either the NN or your actual project)
- rwallace 13y ago
  Then well and good, but alas situations where that will work and deliver business value are rare enough you can easily spend a lifetime as a professional programmer without encountering one.
- tripzilch 13y ago
  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? :)
  - didyousaymeow 13y ago
    I have an upcoming project where we'll be implementing a pattern recognition algorithm - think smart flash cards. I've read up some on timed-repetition and a small amount on how neural networks work. With your experiences, do you have any recommended reading that would help me with the neural network learning curve?
willvarfar 13y ago
Test-Driven Sudoku? :)
huherto 13y ago
Paraphrasing: "You don't know how to do something until you can write a program to do it"

grumps 13y ago

Oh yes the "easy" project... we just need... The real issue is sales...you make the sale because you have to. Then you stick the project on some poor PM/Ba/Dev who will fight with them forever over this stuff. Maybe I'm just bitter about the situation that I continually get stuck in.

hef19898 13y ago
Boy, do I feel with you. But look on the bright side of it, we are not alone, are we? ;-)
- grumps 13y ago
  Yea there are times when I think gee "I'm so happy to be above the ground and vertical." Then I get an irritating email and well that thought flees.
n1ghtmare_ 13y ago
Amen, brother :) !

misterjangles 13y ago

The tricky part is often convincing a client that pre-planning is a necessary part if the process and, though it is billable time, will ultimately save money. Many client don't appreciate that programming is not just writing code. Also you can wind up meeting and planning yourself right out of a gig sometimes - which is fine if the gig wasn't truly necessary. But can be bad for your business if you spend hundreds of hours doing this for no compensation. This is a real situation that happens - you get a client that wants a big project and after many meeting and calls you determine that a Wordpress install will suit them perfectly. Their network guy does the install and for all the money you saved them your reward is that you don't get the gig!

nostrademons 13y ago
If you're billing time & materials (which might be a good idea for a contract of indefinite scope), you'd still get paid for the time spent doing due diligence. You might even be able to sell a time & materials contract on the basis that it gives you an incentive to point out simpler solutions that require less maintenance even if they involve using competing off-the-shelf products.
- misterjangles 13y ago
  Exactly. Good clients will understand "hey, this guy just saved us $150k". Bad clients will think "I just paid a programmer to do nothing!" Learning to recognize and get rid of those bad clients (or convert them into good clients) is a skill that can take a while to learn.
  - hackula1 13y ago
    Along the lines of: "I paid my attorney $10k and I didn't even get to court!"
brianmcconnell 13y ago
The trick then is to get clients who know they just want to "have it taken care of", and have much higher billing suppliers (IP lawyers, pharma experts, etc). In that case, they don't really think twice about paying for process in advance of coding. Pharma is a good example. Being a contract resource for a software company, where management tends to think everything related to software/IT is "easy", is a guaranteed shitty project. They'll second guess and micromanage everything you do. And then when they burn through their OPM, they'll screw you.

perfunctory 13y ago

> Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. If everybody was so picky the size of the IT industry would diminish by 90%.

lifeisstillgood 13y ago
and the success rate? and value delivered?
- weland 13y ago
  How dare you bring technical excellence as an argument? Don't you know this is about money, not performance? Jeez, get an MBA.
  - lifeisstillgood 13y ago
    that took a minute to process ! cheers

shailesh 13y ago

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 guys to create a coherent road map for the system to be built. What tends to happen in practice is a combination of chance, human errors and conflicts in priorities. To survive, we must understand ourselves as consultants, the terrain and the opposing forces (anything that prevents money getting deposited in the bank). Consulting is a business => the individual consultant must shoulder quite a lot on himself: * Advertising himself * Finding work * Meeting prospective customers * Writing proposals * Closing the deal * Writing a contract * Defining the scope of work * Nailing what is to be done and what is to be avoided * Constructing components of software * (In worst cases) baby-sitting customer's devs / ops * Testing his modules * Getting money in his account So, when we talk with customers, there is inherent pressure in closing the deal versus precisely defining everything. Icing on the cake: back of the mind, you might worry about milkman's bills and the birthday gifts to be brought for your kid's friends. Always have a good runway: six months seems optimum. Technically, even three months should suffice, but it is insufficient for the edge case when these three things hold true simultaneously: * You've to walk away from a customer in the middle of a project, and * Dry sales pipeline, and * Unexpected crisis at the personal front: very close friend in need of money for surgery etc. God be with you. Now, back to the main track. The key is to first understand the priorities of stakeholders. The contradictions are easier to grasp once we put ourselves in the individual's shoes: * [Convenience] The users want everything including the kitchen sink, * [Accountability for the risk] They want it yesterday but won't commit to it on paper since you're in early sales stage, * [Cost] The finance folks want stability and the most economical price, * [Availability] The decision maker prefers to spend the least of her time to be spent on this activity, except when it's her pet project. These roles may be played by different people or the same person. Again, we don't have to agree, but acknowledge that things are meant to be imperfect. Most people are actually decent and rational. Now, somehow, the consultant must figure out a good path. To begin, he should have a good handle on: * The industry in which the customer operates, e.g. BFSI, Energy, online marketplaces, food, fashion etc. * The nature of the market: oligopoly, crowded, emerging et al. * The level of Govt. regulation: HIPAA? PCI? * The customer's position: among top tier, mid-size, small firms. * Customer's customers: helps to track the wind. * Standard pain areas in the market. * How customer's competition and partners survive the pain, specifically the differences among the customer's approach and the competitor's ones. * The financial health of the customer: if possible, try to talk with their existing suppliers in other arenas (e.g. the guy who supplies printer cartridges, the cleaning lady etc.). Based on that, assuming we've landed a hot lead, say that we want to convert it to money. There will be a lot of conversations over the phone, e-mail, chats, face to face; what is to be left out of those conversations is really context sensitive. The important parts are: * What problem we're going to solve for all stakeholders? * How we're going to solve it? * Communicating our approach and progress on a timely basis. * Improving Vulcan skills: like money, expression of anger is a great servant but a terrible master. I leave out the details on the development process, since it depends on the individual. Here are a few things which worked for me marvellously in certain contexts and doomed in others: * Setting expectations by explaining the cone of uncertainty in the estimation process. Always be prepared for some customers, who deliberately mislead you that they don't understand the mumbo-jumbo, projecting ignorance as a shield so that they can ruin you on payments. Mostly you should refuse such customers, unless you're in an extreme crisis on multiple fronts. * Writing use cases for the modules / systems I was supposed to work. Most customers say that they don't want any time spent on "documentation," to which I reply that writing a document is not "typing" but "nailing the thoughts to deliver higher quality work." * Creating mock ups using sketching tools (even Excel/LibreOffice can be good enough, if one is pressed too much for time) in the absence of UX designers on the team. * Writing test cases before writing my code. Helps to ease the integration. * Optimizing lazily: progressively refining the artefact (document / mock up / test / code). * Knowing the expected value of each task: (amount of money * satisfaction * improvement in reputation) / (e-mail tennis * stakeholder's understanding of requirements * payment latency * time spent) Finally, reducing it to just one sentence: be nice, believe in yourself and humanity, be multi-dimensional and please heed Guy Kawasaki's advice about reading voraciously and omnivorously. Edit: formatting.

eitally 13y ago

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. <8 months pass> 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.

hef19898 13y ago
Try to keep your spirit up despite all this, especially your team. Things like that were part of the reason why I quit my last job. Completely true is the thing with the superstars. I knew one myself, a genius in warehouse management systems. If I had him on a project, it went smoothly as anything. if I didn't I stayed in development hell for months. But seeing this guys workload, he wasn't off any better. But in retrospect, the general direction the organisation took at my last employer wasn't that bad. Execution lacked, so.
cygwin98 13y ago
If you billed those 900 hours for doing RFP for the customer, it doesn't sound too bad.
- eitally 13y ago
  We couldn't bill them -- it was another SG&A department and we (IT) don't bill them for our work.
  - roel_v 13y ago

Agathos 13y ago

> Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. The formation of this sentence seems odd to me. Why can't we say it's a fun read because it's a classic example etc.?