3 ms·

I worked at Appian within the past five years for an internship. I'm less aware of their success business side, but their software seemed to be falling apart. M

I worked at Appian within the past five years for an internship. I'm less aware of their success business side, but their software seemed to be falling apart. Multiple hundred line classes were copied and pasted around, logging and exceptions were pretty much ignored, vital parts of their stack were deep within deprecated libraries and frameworks with no way out. It did not feel like they valued quality, and a bunch of people felt flat out incompetent. That said, they've done super well for themselves. It sort of blows away this thought of successful startups being full of the best and trying to build the best product. I'm curious what will happen to them down the line.

qweqwe0654 9y ago
Engineering quality != business value
jcadam 9y ago
I applied for a job there back when I lived in NOVA. Didn't get past the HR phone pre-screen. Maybe I should be glad :)
Edmond 9y ago
BPM software is excellent for selling to CIO/C-Suites types, they tend to have a vocabulary that uses business jargon instead of technical jargon which is attractive to business people. The actual product capability matters little after that.
caseysoftware 9y ago
Protip: While we care intensely about "high quality" software, we define it as "well-designed" or "well-abstracted" or "loosely couple" and all kinds of things that matter when you look at source code, customers care about: 1) does it solve my problem? 2) is it reliable enough? ("enough" depends on use case) 3) can I afford it? (not just cash but maybe TCO) Edit: And this applies to most of the "hot startups" too. Ask anyone who has been at a major company through the growth years and ask how "good" their software was. Every single one will share horror stories about late nights, tight deadlines, horrible hacks, and "omg let's rewrite this whole thing!" arguments. As things grow and stability becomes a priority (often customer-driven), things change for the better for the software.
- vdnkh 9y ago
  Customers also care about: 4) How quickly can you fix it? 5) How quickly can you deliver this feature?
  - rmk 9y ago
    In my experience these two asks usually come from the early adopters and savvy customers, who are generally outnumbered by the (newer) customers who just want something that works and fits within a pre-allocated budget category. One notable exception of late has been security fixes. A lot more enterprises have become more aware of the need to patch their systems quickly in response to CVEs etc.
dalfonso 9y ago
>> It sort of blows away this thought of successful startups being full of the best and trying to build the best product. On one of my first projects, I was so afraid of "spaghetti code". Before adding any substantial feature I searched for "best practices" and tried to implement them, made sure my file names and folder structures were organized, wrote unit tests, then wrote integration tests, then manually tested -- all before I had a single customer or another developer on my "team". Looking back, I was very slow. I think it still would've failed if I was a bit faster, but who knows. Then at my next job I had almost the exact same experience as you. 400-600 line methods, no logging, reliance on outdated libraries/frameworks, no documentation. Fixing bugs meant trying to change as little code as possible, because if you actually tried to refactor you would almost definitely end up altering or breaking some other feature. Yet there were large companies that paid for and relied on the software for business critical processes. I'm still trying to figure out what the balance is, but I'm glad to have experienced both ends of the spectrum.

qweqwe0654 9y ago

Engineering quality != business value

jcadam 9y ago

I applied for a job there back when I lived in NOVA. Didn't get past the HR phone pre-screen. Maybe I should be glad :)

Edmond 9y ago

BPM software is excellent for selling to CIO/C-Suites types, they tend to have a vocabulary that uses business jargon instead of technical jargon which is attractive to business people. The actual product capability matters little after that.

caseysoftware 9y ago

Protip: While we care intensely about "high quality" software, we define it as "well-designed" or "well-abstracted" or "loosely couple" and all kinds of things that matter when you look at source code, customers care about: 1) does it solve my problem? 2) is it reliable enough? ("enough" depends on use case) 3) can I afford it? (not just cash but maybe TCO) Edit: And this applies to most of the "hot startups" too. Ask anyone who has been at a major company through the growth years and ask how "good" their software was. Every single one will share horror stories about late nights, tight deadlines, horrible hacks, and "omg let's rewrite this whole thing!" arguments. As things grow and stability becomes a priority (often customer-driven), things change for the better for the software.

vdnkh 9y ago
Customers also care about: 4) How quickly can you fix it? 5) How quickly can you deliver this feature?
- rmk 9y ago
  In my experience these two asks usually come from the early adopters and savvy customers, who are generally outnumbered by the (newer) customers who just want something that works and fits within a pre-allocated budget category. One notable exception of late has been security fixes. A lot more enterprises have become more aware of the need to patch their systems quickly in response to CVEs etc.

dalfonso 9y ago

>> It sort of blows away this thought of successful startups being full of the best and trying to build the best product. On one of my first projects, I was so afraid of "spaghetti code". Before adding any substantial feature I searched for "best practices" and tried to implement them, made sure my file names and folder structures were organized, wrote unit tests, then wrote integration tests, then manually tested -- all before I had a single customer or another developer on my "team". Looking back, I was very slow. I think it still would've failed if I was a bit faster, but who knows. Then at my next job I had almost the exact same experience as you. 400-600 line methods, no logging, reliance on outdated libraries/frameworks, no documentation. Fixing bugs meant trying to change as little code as possible, because if you actually tried to refactor you would almost definitely end up altering or breaking some other feature. Yet there were large companies that paid for and relied on the software for business critical processes. I'm still trying to figure out what the balance is, but I'm glad to have experienced both ends of the spectrum.