6 ms·

> Nothing ever works as soon as an engineer writes code; it is an iterative process. One of my complaints about working in an environment where I am the only p

> Nothing ever works as soon as an engineer writes code; it is an iterative process. One of my complaints about working in an environment where I am the only person who can program is that nobody else understands this. I've taken the time to explain this point to people, and they seem to grasp it fairly well, but once they see something that somewhat resembles the final product they get really impatient. The last 25% of functionality takes far more time than the first 75%, especially once you consider handling edge cases, etc.

dasmoth 9y ago
once they see something that somewhat resembles the final product they get really impatient. (Especially for internal tool) Is it possible that what they've seen is, actually, good enough? Or at least, good enough to solve 90% of the problem while you fill in the missing piece that covers the rest.
- Declanomous 9y ago
  Kind of. There are a few people who I don't mind using tools as soon as I have even a minimum functionality working. Then we have a few people who completely ignore any limitations I put of tools and use them in ways in which they are explicitly not working. Case-in-point: I created a process that automated a particular task. Said task bears a resemblance to another task, but there are a lot of edge cases in the other task. The manager who runs the second task got upset that I had automated one task but not the other, and complained in a senior staff meeting about this. I mentioned that the second process was much more complex, and a lot could go wrong if she tried using the new process for it. Anyways, I took a sick day yesterday, and she had sent an email to me CCing my boss, complaining about how the new process was broken. She had tried changing the settings to work with her process and broken both processes. She is fully convinced I am just keeping tools from her because I don't like her. The reason she doesn't have any tools is because I have to build the most robust tools possible or she'll break everything, and I can automate 10 other processes with that sort of time.
  - monknomo 9y ago
    Maybe it's a false economy to automate other processes if the political fallout from not automating hers is big?
    - Declanomous 9y ago
      Eh, my boss is the director of the organization. I keep him informed of what is going on and he lets me know what to prioritize. So I'm somewhat protected from backlash, it's just tiring having to deal with angry emails because someone doesn't have the same things as someone else. I'd say that my boss generally makes the right decision when it comes to what is best for the organization, and I'm not in the habit of rewarding people for being abusive.
deleted 9y ago
[deleted]
sbov 9y ago
Yes, edge cases can make features pathological. That "simple feature X" might be simple in isolation but when crossed with "simple feature Y" may cause your edge cases, test code, and linecount, to explode. Not all features are a simple additive amount of work. Usually the work to add a feature is relative to the other features that already exist within the system.
taneq 9y ago
Pro tip: Do the user interface last. Or, if you need to do it first for prototyping / mockup reasons, don't show it to anyone you don't have to. Learned that one in my first ever project. We mocked up the entire application in Visual Basic (just windows and buttons, no actual functionality implemented, we just wanted to know if it'd work for them) and then the client got really upset when we couldn't come round and install it the next day. Classic case of failing to manage expectations.
- Declanomous 9y ago
  That's a good tip. I learned that after the first big project I did. Nobody paid any attention to the features, they just wanted me to move buttons back and forth.
  - mmcnl 9y ago
    You're addressing the wrong problem. The real problem is that you're not talking to the right person.
- acdha 9y ago
  That one's hard, however, since it's frequently the case that the user interface is what makes it real to people and leads to plan revisions once they realize that e.g. the cool visualization they asked for doesn't work with 100k data-points. I haven't found a way around this other than careful communication, which works with most but not all clients.
  - woliveirajr 9y ago
    Perhaps doing the user interface in a mockup way. I mean, really like it was draw on paper and not a software-looking software. Like this: https://media.balsamiq.com/img/examples/wiki-sketch.png https://media.balsamiq.com/img/examples/wiki-sketch.png
  - taneq 9y ago
    > I haven't found a way around this other than careful communication, which works with most but not all clients. My wife does this kind of interface mockup presentation as part of her job, whenever she does a client presentation she starts with "so this is a screenshot of the inside of my head..."
paulddraper 9y ago
I think it's the 80/80 rule of software development. The first 80% takes 80% of the time. The last 20% takes the remaining 80%.

dasmoth 9y ago

once they see something that somewhat resembles the final product they get really impatient. (Especially for internal tool) Is it possible that what they've seen is, actually, good enough? Or at least, good enough to solve 90% of the problem while you fill in the missing piece that covers the rest.

Declanomous 9y ago
Kind of. There are a few people who I don't mind using tools as soon as I have even a minimum functionality working. Then we have a few people who completely ignore any limitations I put of tools and use them in ways in which they are explicitly not working. Case-in-point: I created a process that automated a particular task. Said task bears a resemblance to another task, but there are a lot of edge cases in the other task. The manager who runs the second task got upset that I had automated one task but not the other, and complained in a senior staff meeting about this. I mentioned that the second process was much more complex, and a lot could go wrong if she tried using the new process for it. Anyways, I took a sick day yesterday, and she had sent an email to me CCing my boss, complaining about how the new process was broken. She had tried changing the settings to work with her process and broken both processes. She is fully convinced I am just keeping tools from her because I don't like her. The reason she doesn't have any tools is because I have to build the most robust tools possible or she'll break everything, and I can automate 10 other processes with that sort of time.
- monknomo 9y ago
  Maybe it's a false economy to automate other processes if the political fallout from not automating hers is big?
  - Declanomous 9y ago
    Eh, my boss is the director of the organization. I keep him informed of what is going on and he lets me know what to prioritize. So I'm somewhat protected from backlash, it's just tiring having to deal with angry emails because someone doesn't have the same things as someone else. I'd say that my boss generally makes the right decision when it comes to what is best for the organization, and I'm not in the habit of rewarding people for being abusive.

deleted 9y ago

[deleted]

sbov 9y ago

Yes, edge cases can make features pathological. That "simple feature X" might be simple in isolation but when crossed with "simple feature Y" may cause your edge cases, test code, and linecount, to explode. Not all features are a simple additive amount of work. Usually the work to add a feature is relative to the other features that already exist within the system.

taneq 9y ago

Pro tip: Do the user interface last. Or, if you need to do it first for prototyping / mockup reasons, don't show it to anyone you don't have to. Learned that one in my first ever project. We mocked up the entire application in Visual Basic (just windows and buttons, no actual functionality implemented, we just wanted to know if it'd work for them) and then the client got really upset when we couldn't come round and install it the next day. Classic case of failing to manage expectations.

Declanomous 9y ago
That's a good tip. I learned that after the first big project I did. Nobody paid any attention to the features, they just wanted me to move buttons back and forth.
- mmcnl 9y ago
  You're addressing the wrong problem. The real problem is that you're not talking to the right person.
acdha 9y ago
That one's hard, however, since it's frequently the case that the user interface is what makes it real to people and leads to plan revisions once they realize that e.g. the cool visualization they asked for doesn't work with 100k data-points. I haven't found a way around this other than careful communication, which works with most but not all clients.
- woliveirajr 9y ago
  Perhaps doing the user interface in a mockup way. I mean, really like it was draw on paper and not a software-looking software. Like this: https://media.balsamiq.com/img/examples/wiki-sketch.png https://media.balsamiq.com/img/examples/wiki-sketch.png
- taneq 9y ago
  > I haven't found a way around this other than careful communication, which works with most but not all clients. My wife does this kind of interface mockup presentation as part of her job, whenever she does a client presentation she starts with "so this is a screenshot of the inside of my head..."

paulddraper 9y ago

I think it's the 80/80 rule of software development. The first 80% takes 80% of the time. The last 20% takes the remaining 80%.