http://www.theguardian.com/technology/2006/feb/09/guardianwe...
Silo-ing as an organizational principle almost always goes wrong and what you end up with is a stovepipe organization.
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.
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.
Other than that it's pretty useable. At least compared to SAP, which is my only other timesheeting-experience.
The end users usually just have to deal with it, and go whereever they get jobs.
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!
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.
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.
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.
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?"
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.
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.
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. ;-)
It wears on people, but guys in combat get used to other people in their outfit dying eventually. This is nothing compared to that.
I am extremely sympathetic with wanting it to work better, but again, that which cannot be easily measured does not exist.
An alternate strategy is to do this surreptitiously and present it as a fait accompli, but that has risks.
The Schumpeter curve warrants some serious investigation.
We could just call it the Firm Death Clock :) Doesn't scan as well, does 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.
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.
Often the things that make the app hard to work on also make it hard to use.
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.
I accidentally saw a sign that they have a medical simulation lab here at the hospital and for the first time in 5 years I'm seriously considering giving up my own business to go get a day job.
[0] Don't worry too much. He was just a little early. Otherwise very healthy.
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!
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.
?? and the .com doesn't resolve, nor does Google find anything ...
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.