6 ms·

I once worked as a consultant to help users implement some software. I moved on to the development of that software, knowing the dozens of areas that could be i

I once worked as a consultant to help users implement some software. I moved on to the development of that software, knowing the dozens of areas that could be improved to make life easier for the users, and honestly with little effort (it's a web app, I did that before the consultancy stuff). At that point in time, that was my dream -- I wanted to help make people's lives a little bit easier, and the people I helped would be those who used our software. After around a year or so of implementing questionable features, I attempted to get approval for updates to old, well used features to improve them (stability and convenience focused, really), but was shot down. This wouldn't sell the software, because it worked well enough, and we needed more revenue more than retaining old customers. At that point I understood that after the software is sold the customer will be too ingrained into the product to leave without financial repercussions. A while later, we got bought out by Big Company, so that strategy apparently worked. BC doesn't give half a shit about anything we ever did, and we piled on the features release after release with little concern about anything else. I tried a couple times after the buyout to get approved for existing product improvements, but always got shot down. I continue to find it odd how the company can be so profit oriented, and yet so averse to improvements. I suppose I'm just wrong or don't actually understand. Either way, it makes it very hard to care about my work these days.

martincmartin 11y ago
If your customers are big companies, then there's another dynamic: the people who make decisions about the software are usually not the ones who use it. So a large part of their decision is driven by how the software is described on paper, i.e. by feature bullet points. You end up with lotus notes. http://www.theguardian.com/technology/2006/feb/09/guardianweeklytechnologysection http://www.theguardian.com/technology/2006/feb/09/guardianwe...
- cordite 11y ago
  9000% true. The end users usually just have to deal with it, and go whereever they get jobs.
- dredmorbius 11y ago
  How does GNOME fit that theory?
  - jimbokun 11y ago
    With open source, the software is often developed to meet the needs and priorities of the developers. So if your needs and priorities are similar, it will likely work well for you. Otherwise, maybe not so much.
  - creshal 11y ago
    Gnome's development is mainly driven by RedHat's needs nowadays. It shows.
    - et2o 11y ago
      I'm curious, how does it show?
- CountSessine 11y ago
  Yes; exactly. Silo-ing in large companies where software acquisition, software deployment, and software use are separate functions in the organization is probably the defining influence on 'enterprise software'. This is why so much of it is so bad (sometimes in trivial, easy to change ways), why it's typically so expensive, and why it sometimes so narrowly satisfies stated requirements that it creates whole new problems for the organization. Silo-ing as an organizational principle almost always goes wrong and what you end up with is a stovepipe organization. https://en.wikipedia.org/wiki/Stovepipe_(organisation) https://en.wikipedia.org/wiki/Stovepipe_(organisation)
- astockwell 11y ago
  This is exactly why so many terrible "features" and design patterns keep showing up in web sites: People calling the shots are not the developers. They "saw this on XYZ's successful site, plz implement today".
  - Reedx 11y ago
    Yep. The latest one seems to be newsletter popups that are suddenly infecting the web at large.
    - walterbell 11y ago
      At least newsletters support open-standard email "push" rather than the walled-garden-de-jour, after publishers lost their investments in "followers" to filter algorithms.
    - Donzo 11y ago
      Pop ups are bad in general. IMO, the worst are the full page, content-blocking, app install requests that appear on thin-content sites. It's preposterous. You've proven that you can't be trusted to present your website content in an acceptable manner, and you want me to install your software? Instant back button.
  - duderific 11y ago
    Hang on though. The people calling the shots, or at least providing feedback, should be the end users, not the developers. Usually the developers do not use the software they're building. In rare cases, the developers "eat their own dog food" but this is often not the case.
    - astockwell 11y ago
      I absolutely agree when the web site is a tech product/application. I was more taking a stab at major news/media outlets and other "content" sites, whose non-technical "executives" blithely dictate that their devs perpetuate this buffoonery.
- pasbesoin 11y ago
  IBM's Rational toolset of a decade or a bit more ago, still makes me shudder.
  - tumdum_ 11y ago
    We are still using IBM Rational Rhapsody here. It's crude application, but it does what's advertised.
  - foo42 11y ago
    I had to use that in my last job (and lotus for that matter). All tooling decisions were made by another part of the org in another country. We had no say. When I quit I gave "poor tooling" as my primary reason in my exit interview.
- branchless 11y ago
  Lotus notes was just so odd. You'd sit down to open your mail and wonder what year it was. 1972?
- malkia 11y ago
  For me, the most hated app in the previous company I worked for (Treyarch, part of Activision) was Kronos (kronos.com). It was the "vacation"/time-off/etc. application. Almost all studio was Windows, and you had to use specific browser, with specific Java installed (for some reason our integration/use of it required java in the browser - that was at least year ago). When you open the web-app, sometimes it might not work, when it does it starts with the "bereavement" page (wtf). Then if you want to request vacation that crosses weekends, you have to do it for individual ranges of normal work days. e.g. Also had to be careful not to select work holidays (MLK, 4th July, etc.) That was my use of it... for very short amount of time I was manager to an intern, and had to watch and clock their hours. I had to be trained for 2hr, and still did not get it (I'm a software engineer... duh). But then people claimed it had better new UI, which we did not use (reason unknown), and was pretty powerful.
  - auxym 11y ago
    Ha, I work for BigCo, and we use Kronos for timesheets. We recently transitioned to win7 (from XP), and to get Kronos working again we have to run some virtualization app (citrix maybe? can't remember right now, definitely a vmware product though) to run IE8 and some obsolete java version. All for timesheets. Other than that it's pretty useable. At least compared to SAP, which is my only other timesheeting-experience.
  - awakeasleep 11y ago
    You'll be sad to know that Kronos continues to make life miserable for employees and managers in businesses around the world.
- gaius 11y ago
  I've always wanted to visit SAP headquarters in Germany and see how they book their own vacations and submit their own expenses. It can't be with their own software...
ArkyBeagle 11y ago
If you can't make the sale on a value-added basis, then that's that. As you said - "it worked well enough". You/they can't measure those improvements, so they don't exist. What they may know and you are missing is the product's position on the Schumpeter curve. When it's really bad is when one of your coworkers spends months assembling the data to show that the defects cost them money. It probably cost more to do that than to fix it in the first place. "Move fast and break things." "Yes, but what if the things cost $50,000?"
- lost_name 11y ago
  You're correct, of course, and the Schumpeter curve is not something I'd heard of (I'm not sure that's the textbook name, but I'm sure it's the same concept) and is kind of interesting and frustrating at the same time. Speaking from a strictly business standpoint I understand the motivation behind these things, but from my day to day programming perspective -- where the revenue doesn't come back to me in any way and building the Next Big Feature is really just looking for a spot for it to fit in among the bramble of previous releases -- all I want is for the software to work better. I tend to think of it as just knowing too much, but maybe it's just time to move on.
  - click170 11y ago
    I'm with you. I'm there to make the software better. But the company is there to make money, and improving the software sadly doesn't always make more money. For me, I fill the need of writing better software by working on Foss projects in my spare time because is satisfies that itch so I don't have to try and satisfy it at work. On the other hand I really feel like this is one thing that makes Foss software better IMO than proprietary software. Foss Devs can spend hours working on something that turns out to have no performance impact at all, the point is they have the freedom to pursue that, and that in corporate development the norm is that those issues just never get raised, let alone fixed.
    - mikekchar 11y ago
      Interestingly, I have mostly thought the way you do. In the past few years, though, I've started to change my mind. I've always thought that you could look at it like a graph. On one axis there is software quality and on the other axis there is return on investment. The graph is undefined at 0, but essentially, as you increase software quality, ROI increases. At some point, it starts to dip down -- more quality takes more time, but provides little additional monetary benefit. The sweet spot on the graph depends on the situation, but you are always balancing those two forces. It seems quite obvious that it works that way, but I think that's because we are using a definition of software quality that is not necessarily so useful. In fact, one of the biggest problems we have in this industry is that "good code" is highly subjective. Usually "good code" == "my code" (possibly with the proviso "that I wrote recently"). Similarly, we think that with enough time we will be able to find the perfect design to represent the problem (now and in the future). I think this view is what causes us to come to the wrong conclusion about ROI vs quality. If I define quality in a different way -- the ability for anyone on the team to understand and modify the software quickly, we might find that we have a different looking curve. As I have gotten older, I have discovered that I'm not nearly as confident about my designs as I was when I was younger. Now, I quite often experience the situation where I think, "There are many options for the design here. I don't actually know what is best yet, because we haven't written enough code in this area. So I'm not going to play with it". An earlier version of me would look at the code and conclude that it was sloppy. The new me is trying to avoid locking developers into a design decision that might turn out to be sub-optimal in the long run. In other words, avoiding making a commitment as long as possible (but not longer). Or if you want to look at it a different way, we have all experienced code bases that are hard to work with because they make seemingly arbitrary choices that we have to work around. Or that have unfortunate design decisions that are baked into the code and impossible to refactor out. I will submit that this is generally a result of trying to "do it right" and failing. I work with at least as much of this kind of code as I do with unstable spaghetti code that breaks whenever you breathe on it (the result of abandoning quality). To sum up, I think that as long as your project is going to last for more than about 2 months, good quality code has a much higher ROI than poor quality code. Where we get into trouble is that most developers do not know what good quality code looks like and often over-design/over-commit to the detriment of both the code base and the ROI. I will suggest that at some point, as developers spend more time trying to "do it right", they actually end up with less flexible code that can't react to the surprising requirement changes that are likely to come in the future. Which is not really a helpful insight because it basically says that you need to hire better/more experienced programmers to have good code bases that give you better ROI. ;-)
kelukelugames 11y ago
Have you seen the crap UI doctors use?
- CyberDildonics 11y ago
  Tell me more about this. I've heard general stories but I want to see how deep the rabbit hole goes.
  - sanotehu 11y ago
    A lot of it is essentially hacking around the fact that medicine & hospitals weren't designed for computers. For example: we used to (still do) keep large files of old notes for patients. In the worst cases think reams of paper three inches thick held together by the flimsiest of plastic ties. The solution for computerising this? Scan it all. Categorise by date and medical specialty. Unfortunately using this database turns out to be horrendously slow. Each doctor has to download each page from the database in order to look at it and make sure it's not the page they are looking for (no or poor text recognition). As you can imagine, hundreds of doctors doing this at 9am in the morning grinds the network to a halt. That's just one component of the system we use every day - I have more!
    - CyberDildonics 11y ago
      That sounds like a ridiculous waste of expensive time. I'm interested in more (and I haven't been able to find out how to direct message)
  - cwilkes 11y ago
    A word of advice: don't ever get into the medical software field. I've tried it twice and saw the same problem each time. The sales cycle is a year long. At the end of the year the result is either "we are sticking with BigCo's crap that they told us they would improve the last 5 years" or "budgets are due and they need a new wing so ours was cut" A coworker explained it perfectly: the industry is run in fear. Fear that if you buy software that fails you will be fired. Fear that if someone across the street buys some software and it works you better get it too.
WA 11y ago
And sometimes, it's not even about financial repercussions. A dev thinks that the software can be improved in some way or another, but the users don't even want that improvement. They got used to the interface and are just fine with it. This is what happens to me occasionally with my web app. The design is the same for 5 years now. I'm tired of it, it clearly has limitations, but users are very happy and new users compliment me on the "clean and great design". I really have to fight the urge to make a major redesign and rewrite huge chunks of the code base, because it wouldn't solve any problems users have.
- hinkley 11y ago
  And the nasty part of this trap? If someone does start mimicking you, but with a clean new UI, and your market share starts to slip, so you say "fuck it, I'm gonna do it that way too", then you will force your users to make a choice. Stay, and have to relearn the whole website, or leave, and have to relearn the whole website. I feel like one thing I've learned the hard way is there is such a thing as getting successful too soon. Once people start voting with their feet or wallets on your solution, you're stuck with it. "We'll fix it later"? "Later" is gone, kids. There is no "later" anymore, we have what we have. If you don't like it it's time to start on a new project.
  - chii 11y ago
    could you not incrementally improve the UI, without a drastic surgery of the UI? For example, add an extra screen here or there, add theming support, then allow UI customization, then, add a new IU selectable as a new theme, etc etc.
    - hinkley 11y ago
      If you chose the wrong abstraction for the project, it's often reflected in the logical structure of the app and it takes some serious creativity to correct it without changing the UI very much, IME. Often the things that make the app hard to work on also make it hard to use.
- thirdsun 11y ago
jdcskillet 11y ago
I work in a very similar environment. I thought forcing a change would work, "they'll see, if I just work on this and show them", and technically it did. Except it then became the norm. Now if we don't deliver X number of features in tight deadlines plus all the expected but not well thought out "improvements", it is looked at like a failure by the clients. My point : setting expectations internally and externally is equally important. Don't go too far off the reservation with your ideas, but quite frankly, you're too valuable to completely stop you. Find a happy medium that works till you gain the skills you need to possibly move yourself elsewhere (internally or externally). Not the worlds greatest advice, not the way I would want someone to start off doing, but something I am and feel I had to do to make my life more meaningful. Good luck!
- hinkley 11y ago
  I find a plumber or electrician analogy works pretty well here. They have a job to do, there are only so many ways to do it that aren't stark raving mad, and they'll be fucked if they're going to do it your way because your ten minutes of thinking about the problem space informs you it's the 'right thing to do'.
eitally 11y ago
Most big software companies do formal CSAT surveys. If their customers are consistently satisfied, it's incredibly hard to pitch incremental, non-revenue generating improvements successfully. This happens even at the biggest & best tech companies.
fsloth 11y ago
I think features-over-quality is a common priorization. From managerial point of view it's hard to discern sane quality improvements from just changing the code because of aesthetics if there is no clear business driver.
Tactic 11y ago
The problem here is you changed customers and didn't realize it. In the beginning your customer was the end user as you helped them implement. When you went to development your customer was no longer the end user but the business unit. It is their job to determine what the end user needs. Your job is to ensure business gets what they want. Take pride in doing a good job for them. You may want to consider product design or starting your own project so you can do the product design, though. It sounds more like what you want if that is where you find your joy.
- woebtz 11y ago
  It took a stressful few months for me to make this similar realization. I don't know why it felt so profound at the time, but I imagine a lot of developers (myself included) get their start wanting to create stuff that people want [to use] or that will help their company [be more successful]. Unfortunately, the developer's primary job isn't to make business decisions/ideas and fighting that battle for life and death is many times a lost cause. Fortunately, a good attitude to takeaway is to always have pride in doing good work and believing that a good idea is still a good idea even if you can't convince anyone else (today). Tomorrow, you can wake up and try again.
hinkley 11y ago
I quit a job to go work for a tool maker, because this sort of stuff matters to me. What I didn't get (and possibly still don't) is that working for someone making tools, you make the tools they want to sell, not the tools you wanted to build. It was awful to be that close to a problem and be powerless to do much about it. That big sheet of plate glass became my home, with my nose permanently squished against it. At this stage I'm pretty confident that this is why and when open source operates well. There is basically nobody to stop you from trying something out, except yourself.
melicerte 11y ago
Why don't you go And build your own software Company? Time To believe in yourself And put your balls on the table To prove To yourself that you are right ! Circumstancies were a bit different but i left a bc for the exact same reason (i would not care about my work after being repetively shot down by my top management on ideas I believe were the right things To do). I started my own company 6 years ago. We are now a team of ten worker And I work for some BCs who believe what i say is the right thing To do because of my xp and the trust relationship we have...
- Terr_ 11y ago
  It looks like your post contains a secret code using seemingly-random capitalization, but all I can decipher is ACTTTTAT...
  - imron 11y ago
    Include the capitals at the start of each sentence and then finish with .com
    - iofj 11y ago
      >>> "".join(c for c in x if c == c.upper() and c.isalpha()) 'WACTTATTCITIWAIBCT' ?? and the .com doesn't resolve, nor does Google find anything ...
  - spinningarrow 11y ago
    I think it might have something to do with DNA.

martincmartin 11y ago

If your customers are big companies, then there's another dynamic: the people who make decisions about the software are usually not the ones who use it. So a large part of their decision is driven by how the software is described on paper, i.e. by feature bullet points. You end up with lotus notes. http://www.theguardian.com/technology/2006/feb/09/guardianweeklytechnologysection http://www.theguardian.com/technology/2006/feb/09/guardianwe...

cordite 11y ago
9000% true. The end users usually just have to deal with it, and go whereever they get jobs.
dredmorbius 11y ago
How does GNOME fit that theory?
- jimbokun 11y ago
  With open source, the software is often developed to meet the needs and priorities of the developers. So if your needs and priorities are similar, it will likely work well for you. Otherwise, maybe not so much.
- creshal 11y ago
  Gnome's development is mainly driven by RedHat's needs nowadays. It shows.
  - et2o 11y ago
    I'm curious, how does it show?
CountSessine 11y ago
Yes; exactly. Silo-ing in large companies where software acquisition, software deployment, and software use are separate functions in the organization is probably the defining influence on 'enterprise software'. This is why so much of it is so bad (sometimes in trivial, easy to change ways), why it's typically so expensive, and why it sometimes so narrowly satisfies stated requirements that it creates whole new problems for the organization. Silo-ing as an organizational principle almost always goes wrong and what you end up with is a stovepipe organization. https://en.wikipedia.org/wiki/Stovepipe_(organisation) https://en.wikipedia.org/wiki/Stovepipe_(organisation)
astockwell 11y ago
This is exactly why so many terrible "features" and design patterns keep showing up in web sites: People calling the shots are not the developers. They "saw this on XYZ's successful site, plz implement today".
- Reedx 11y ago
  Yep. The latest one seems to be newsletter popups that are suddenly infecting the web at large.
  - walterbell 11y ago
    At least newsletters support open-standard email "push" rather than the walled-garden-de-jour, after publishers lost their investments in "followers" to filter algorithms.
  - Donzo 11y ago
    Pop ups are bad in general. IMO, the worst are the full page, content-blocking, app install requests that appear on thin-content sites. It's preposterous. You've proven that you can't be trusted to present your website content in an acceptable manner, and you want me to install your software? Instant back button.
- duderific 11y ago
  Hang on though. The people calling the shots, or at least providing feedback, should be the end users, not the developers. Usually the developers do not use the software they're building. In rare cases, the developers "eat their own dog food" but this is often not the case.
  - astockwell 11y ago
    I absolutely agree when the web site is a tech product/application. I was more taking a stab at major news/media outlets and other "content" sites, whose non-technical "executives" blithely dictate that their devs perpetuate this buffoonery.
pasbesoin 11y ago
IBM's Rational toolset of a decade or a bit more ago, still makes me shudder.
- tumdum_ 11y ago
  We are still using IBM Rational Rhapsody here. It's crude application, but it does what's advertised.
- foo42 11y ago
  I had to use that in my last job (and lotus for that matter). All tooling decisions were made by another part of the org in another country. We had no say. When I quit I gave "poor tooling" as my primary reason in my exit interview.
branchless 11y ago
Lotus notes was just so odd. You'd sit down to open your mail and wonder what year it was. 1972?
malkia 11y ago
For me, the most hated app in the previous company I worked for (Treyarch, part of Activision) was Kronos (kronos.com). It was the "vacation"/time-off/etc. application. Almost all studio was Windows, and you had to use specific browser, with specific Java installed (for some reason our integration/use of it required java in the browser - that was at least year ago). When you open the web-app, sometimes it might not work, when it does it starts with the "bereavement" page (wtf). Then if you want to request vacation that crosses weekends, you have to do it for individual ranges of normal work days. e.g. Also had to be careful not to select work holidays (MLK, 4th July, etc.) That was my use of it... for very short amount of time I was manager to an intern, and had to watch and clock their hours. I had to be trained for 2hr, and still did not get it (I'm a software engineer... duh). But then people claimed it had better new UI, which we did not use (reason unknown), and was pretty powerful.
- auxym 11y ago
  Ha, I work for BigCo, and we use Kronos for timesheets. We recently transitioned to win7 (from XP), and to get Kronos working again we have to run some virtualization app (citrix maybe? can't remember right now, definitely a vmware product though) to run IE8 and some obsolete java version. All for timesheets. Other than that it's pretty useable. At least compared to SAP, which is my only other timesheeting-experience.
- awakeasleep 11y ago
  You'll be sad to know that Kronos continues to make life miserable for employees and managers in businesses around the world.
gaius 11y ago
I've always wanted to visit SAP headquarters in Germany and see how they book their own vacations and submit their own expenses. It can't be with their own software...

ArkyBeagle 11y ago

If you can't make the sale on a value-added basis, then that's that. As you said - "it worked well enough". You/they can't measure those improvements, so they don't exist. What they may know and you are missing is the product's position on the Schumpeter curve. When it's really bad is when one of your coworkers spends months assembling the data to show that the defects cost them money. It probably cost more to do that than to fix it in the first place. "Move fast and break things." "Yes, but what if the things cost $50,000?"

lost_name 11y ago
You're correct, of course, and the Schumpeter curve is not something I'd heard of (I'm not sure that's the textbook name, but I'm sure it's the same concept) and is kind of interesting and frustrating at the same time. Speaking from a strictly business standpoint I understand the motivation behind these things, but from my day to day programming perspective -- where the revenue doesn't come back to me in any way and building the Next Big Feature is really just looking for a spot for it to fit in among the bramble of previous releases -- all I want is for the software to work better. I tend to think of it as just knowing too much, but maybe it's just time to move on.
- click170 11y ago
  I'm with you. I'm there to make the software better. But the company is there to make money, and improving the software sadly doesn't always make more money. For me, I fill the need of writing better software by working on Foss projects in my spare time because is satisfies that itch so I don't have to try and satisfy it at work. On the other hand I really feel like this is one thing that makes Foss software better IMO than proprietary software. Foss Devs can spend hours working on something that turns out to have no performance impact at all, the point is they have the freedom to pursue that, and that in corporate development the norm is that those issues just never get raised, let alone fixed.
  - mikekchar 11y ago
    Interestingly, I have mostly thought the way you do. In the past few years, though, I've started to change my mind. I've always thought that you could look at it like a graph. On one axis there is software quality and on the other axis there is return on investment. The graph is undefined at 0, but essentially, as you increase software quality, ROI increases. At some point, it starts to dip down -- more quality takes more time, but provides little additional monetary benefit. The sweet spot on the graph depends on the situation, but you are always balancing those two forces. It seems quite obvious that it works that way, but I think that's because we are using a definition of software quality that is not necessarily so useful. In fact, one of the biggest problems we have in this industry is that "good code" is highly subjective. Usually "good code" == "my code" (possibly with the proviso "that I wrote recently"). Similarly, we think that with enough time we will be able to find the perfect design to represent the problem (now and in the future). I think this view is what causes us to come to the wrong conclusion about ROI vs quality. If I define quality in a different way -- the ability for anyone on the team to understand and modify the software quickly, we might find that we have a different looking curve. As I have gotten older, I have discovered that I'm not nearly as confident about my designs as I was when I was younger. Now, I quite often experience the situation where I think, "There are many options for the design here. I don't actually know what is best yet, because we haven't written enough code in this area. So I'm not going to play with it". An earlier version of me would look at the code and conclude that it was sloppy. The new me is trying to avoid locking developers into a design decision that might turn out to be sub-optimal in the long run. In other words, avoiding making a commitment as long as possible (but not longer). Or if you want to look at it a different way, we have all experienced code bases that are hard to work with because they make seemingly arbitrary choices that we have to work around. Or that have unfortunate design decisions that are baked into the code and impossible to refactor out. I will submit that this is generally a result of trying to "do it right" and failing. I work with at least as much of this kind of code as I do with unstable spaghetti code that breaks whenever you breathe on it (the result of abandoning quality). To sum up, I think that as long as your project is going to last for more than about 2 months, good quality code has a much higher ROI than poor quality code. Where we get into trouble is that most developers do not know what good quality code looks like and often over-design/over-commit to the detriment of both the code base and the ROI. I will suggest that at some point, as developers spend more time trying to "do it right", they actually end up with less flexible code that can't react to the surprising requirement changes that are likely to come in the future. Which is not really a helpful insight because it basically says that you need to hire better/more experienced programmers to have good code bases that give you better ROI. ;-)

kelukelugames 11y ago

Have you seen the crap UI doctors use?

CyberDildonics 11y ago
Tell me more about this. I've heard general stories but I want to see how deep the rabbit hole goes.
- sanotehu 11y ago
  A lot of it is essentially hacking around the fact that medicine & hospitals weren't designed for computers. For example: we used to (still do) keep large files of old notes for patients. In the worst cases think reams of paper three inches thick held together by the flimsiest of plastic ties. The solution for computerising this? Scan it all. Categorise by date and medical specialty. Unfortunately using this database turns out to be horrendously slow. Each doctor has to download each page from the database in order to look at it and make sure it's not the page they are looking for (no or poor text recognition). As you can imagine, hundreds of doctors doing this at 9am in the morning grinds the network to a halt. That's just one component of the system we use every day - I have more!
  - CyberDildonics 11y ago
    That sounds like a ridiculous waste of expensive time. I'm interested in more (and I haven't been able to find out how to direct message)
- cwilkes 11y ago
  A word of advice: don't ever get into the medical software field. I've tried it twice and saw the same problem each time. The sales cycle is a year long. At the end of the year the result is either "we are sticking with BigCo's crap that they told us they would improve the last 5 years" or "budgets are due and they need a new wing so ours was cut" A coworker explained it perfectly: the industry is run in fear. Fear that if you buy software that fails you will be fired. Fear that if someone across the street buys some software and it works you better get it too.

WA 11y ago

And sometimes, it's not even about financial repercussions. A dev thinks that the software can be improved in some way or another, but the users don't even want that improvement. They got used to the interface and are just fine with it. This is what happens to me occasionally with my web app. The design is the same for 5 years now. I'm tired of it, it clearly has limitations, but users are very happy and new users compliment me on the "clean and great design". I really have to fight the urge to make a major redesign and rewrite huge chunks of the code base, because it wouldn't solve any problems users have.

hinkley 11y ago
And the nasty part of this trap? If someone does start mimicking you, but with a clean new UI, and your market share starts to slip, so you say "fuck it, I'm gonna do it that way too", then you will force your users to make a choice. Stay, and have to relearn the whole website, or leave, and have to relearn the whole website. I feel like one thing I've learned the hard way is there is such a thing as getting successful too soon. Once people start voting with their feet or wallets on your solution, you're stuck with it. "We'll fix it later"? "Later" is gone, kids. There is no "later" anymore, we have what we have. If you don't like it it's time to start on a new project.
- chii 11y ago
  could you not incrementally improve the UI, without a drastic surgery of the UI? For example, add an extra screen here or there, add theming support, then allow UI customization, then, add a new IU selectable as a new theme, etc etc.
  - hinkley 11y ago
    If you chose the wrong abstraction for the project, it's often reflected in the logical structure of the app and it takes some serious creativity to correct it without changing the UI very much, IME. Often the things that make the app hard to work on also make it hard to use.
thirdsun 11y ago

jdcskillet 11y ago

I work in a very similar environment. I thought forcing a change would work, "they'll see, if I just work on this and show them", and technically it did. Except it then became the norm. Now if we don't deliver X number of features in tight deadlines plus all the expected but not well thought out "improvements", it is looked at like a failure by the clients. My point : setting expectations internally and externally is equally important. Don't go too far off the reservation with your ideas, but quite frankly, you're too valuable to completely stop you. Find a happy medium that works till you gain the skills you need to possibly move yourself elsewhere (internally or externally). Not the worlds greatest advice, not the way I would want someone to start off doing, but something I am and feel I had to do to make my life more meaningful. Good luck!

hinkley 11y ago
I find a plumber or electrician analogy works pretty well here. They have a job to do, there are only so many ways to do it that aren't stark raving mad, and they'll be fucked if they're going to do it your way because your ten minutes of thinking about the problem space informs you it's the 'right thing to do'.

eitally 11y ago

Most big software companies do formal CSAT surveys. If their customers are consistently satisfied, it's incredibly hard to pitch incremental, non-revenue generating improvements successfully. This happens even at the biggest & best tech companies.

fsloth 11y ago

I think features-over-quality is a common priorization. From managerial point of view it's hard to discern sane quality improvements from just changing the code because of aesthetics if there is no clear business driver.

Tactic 11y ago

The problem here is you changed customers and didn't realize it. In the beginning your customer was the end user as you helped them implement. When you went to development your customer was no longer the end user but the business unit. It is their job to determine what the end user needs. Your job is to ensure business gets what they want. Take pride in doing a good job for them. You may want to consider product design or starting your own project so you can do the product design, though. It sounds more like what you want if that is where you find your joy.

woebtz 11y ago
It took a stressful few months for me to make this similar realization. I don't know why it felt so profound at the time, but I imagine a lot of developers (myself included) get their start wanting to create stuff that people want [to use] or that will help their company [be more successful]. Unfortunately, the developer's primary job isn't to make business decisions/ideas and fighting that battle for life and death is many times a lost cause. Fortunately, a good attitude to takeaway is to always have pride in doing good work and believing that a good idea is still a good idea even if you can't convince anyone else (today). Tomorrow, you can wake up and try again.

hinkley 11y ago

I quit a job to go work for a tool maker, because this sort of stuff matters to me. What I didn't get (and possibly still don't) is that working for someone making tools, you make the tools they want to sell, not the tools you wanted to build. It was awful to be that close to a problem and be powerless to do much about it. That big sheet of plate glass became my home, with my nose permanently squished against it. At this stage I'm pretty confident that this is why and when open source operates well. There is basically nobody to stop you from trying something out, except yourself.

melicerte 11y ago

Why don't you go And build your own software Company? Time To believe in yourself And put your balls on the table To prove To yourself that you are right ! Circumstancies were a bit different but i left a bc for the exact same reason (i would not care about my work after being repetively shot down by my top management on ideas I believe were the right things To do). I started my own company 6 years ago. We are now a team of ten worker And I work for some BCs who believe what i say is the right thing To do because of my xp and the trust relationship we have...

Terr_ 11y ago
It looks like your post contains a secret code using seemingly-random capitalization, but all I can decipher is ACTTTTAT...
- imron 11y ago
  Include the capitals at the start of each sentence and then finish with .com
  - iofj 11y ago
    >>> "".join(c for c in x if c == c.upper() and c.isalpha()) 'WACTTATTCITIWAIBCT' ?? and the .com doesn't resolve, nor does Google find anything ...
- spinningarrow 11y ago
  I think it might have something to do with DNA.