Better to get the software out the door fast than to be able to support more than 10 users at any one time, eh?
Actually, yes. If you spend all the time trying to make it perform, you will have zero users. If it takes a year to get out the door, it will be obsolete before it exists. You gotta get it out the door yesterday so you can actually get some users. Scaling before you have users is solving a problem you don't have. Get users, then scale.
So says someone who can't get anything out the door. Then again, trying to make things scale is not the reason I am unable to launch.
I mean look at Twitter. It crashed all over the fuck, but it's still around.
Also, it's hard to rewrite your code to scale properly. However, there are many ways you can use IT to get really shitty code to scale in the mean time. Load balancers, better hardware, more machines, lots of options. You can get really far with a little bit of IT.
I mean look at Twitter. It crashed all over the fuck, but it's still around.
Also, it's hard to rewrite your code to scale properly. However, there are many ways you can use IT to get really shitty code to scale in the mean time. Load balancers, better hardware, more machines, lots of options. You can get really far with a little bit of IT.
We may need to get this out of a 'jobs' discussion but,
Twitter - RoR but if I'm sure everyone dreams of having those scalability issues. Scalable solution - I go 'throw more hardware at it' every time if possible. Performance/scaling considerations in code generally make code less maintainable.
Twitter were the example of what I was thinking of. I guess maybe I'm too old school to think that something should be done "right" at the start. Stitch in time saves nine and all that.
For instance, I'm working at a small company developing an in house ERP system. We add new features all the time, patch constantly. It's constantly engaging.
But far too often I find myself going back and fixing things that others had done for the sake of speed of release rather than done properly in the first place.
Sorry, it is nothing more than my own personal pet peeve.
I guess maybe I'm too old school to think that something should be done "right" at the start. Stitch in time saves nine and all that.
My experience is the customer never knows what they really want until it's in front of them. If you have an engaged customer I believe you will see better results with an iterative approach.
Twitter were the example of what I was thinking of. I guess maybe I'm too old school to think that something should be done "right" at the start. Stitch in time saves nine and all that.
Doing it right takes a lot more time. Time is money. Look at the world of software. People have definitely gotten used to bugs and flaws all over the place. They really aren't a big deal from a business perspective, even though they drive engineers crazy. If you want to do good business, just make it as fast as possible and get it out. Only fix what you absolutely have to fix. If you actually succeed and have a ton of users, you will have time and money to clean it up later, if it's even necessary. If you don't get the users, then you wasted all that time making something perfect that's never going to be used.
My experience is the customer never knows what they really want until it's in front of them. If you have an engaged customer I believe you will see better results with an iterative approach.
Writing the software iteratively isn't quite the same as doing the right thing as it were. That more about understanding what the customer needs, rather than proper implementation of the customers requirements.
It maybe faster to populate that combo box with 10 hard coded values than it is to create a list in the DB to populate it, along with the requisite management of said values, but after how many times being asked to add one more value is it correct to make it so the customer can manage the values themselves? (stupid example that came up recently, sometimes I wonder if my coworkers actually think some things through)
Writing the software iteratively isn't quite the same as doing the right thing as it were.
It's more of an agile thing. If you have a solid unit test environment then the risk of refactoring your 'bad code' at a later date is mitigated somewhat.
It maybe faster to populate that combo box with 10 hard coded values
Was it easy to predict that the customer would want more values in the future?
Writing the software iteratively isn't quite the same as doing the right thing as it were. That more about understanding what the customer needs, rather than proper implementation of the customers requirements.
It maybe faster to populate that combo box with 10 hard coded values than it is to create a list in the DB to populate it, along with the requisite management of said values, but after how many times being asked to add one more value is it correct to make it so the customer can manage the values themselves? (stupid example that came up recently, sometimes I wonder if my coworkers actually think some things through)
I've seen basically that same exact situation many times. The thing is, the customer will only care if they're actually smart, which they usually aren't. If they were, they would have written the app themselves.
But yeah, it takes maybe five minutes to make that kind of change, but how many such five minute changes are there all around the system? A lot. If you do them all, it adds up to a lot of work. Doing it the stupidest fastest most copy-pastest no code-reuse way is the fastest way to get the job done. If the system gets the primary job done, then go with it. Your engineering brain won't like it, but that's the way to succeed in the software business. Just look at the rich guys. They all got there by rushing shitty software out the door that at least got the job done. And even though it's far from perfect, they beat the other guy. It is extremely rare that well engineered software is successful in the marketplace.
The thing is, the customer will only care if they're actually smart, which they usually aren't. If they were, they would have written the app themselves.
Another trait of yours, Scott, is to assume that anyone who cannot or does not do what you do is not smart. My customer is the NASA Earth Science community. They are SMART. They use that smartness to do earth science not provide ingest, archive, distribution and processing systems for their data.
It is extremely rare that well engineered software is successful in the marketplace.
But I agree with this. Propellerheads software being my favourite exception that proves the rule.
Another trait of yours, Scott, is to assume that anyone who cannot or does not do what you do is not smart. My customer is the NASA Earth Science community. They are SMART. They use that smartness to do earth science not provide ingest, archive, distribution and processing systems for their data.
I mean computer smart as in, they could have done the work themselves and don't need you to do it.
Another trait of yours, Scott, is to assume that anyone who cannot or does not do what you do is not smart. My customer is the NASA Earth Science community. They are SMART. They use that smartness to do earth science not provide ingest, archive, distribution and processing systems for their data.
I mean computer smart as in, they could have done the work themselves and don't need you to do it.
Fair enough. But our NASA customers (and I will admit that this is the only customer I know) are extremely savvy when it comes to this. I guess we are lucky in this respect.
My engineering brain explodes at "git-er-dun" sort of mentality. I dig agile, but I do like thinking forward a bit too. I suppose it is a good things that my only customers are my coworkers. We do some 4 or 5 releases/patches a day so I'm not adverse to just one feature at a time, incrementally improving a system. Perfection is asking a bit much but maybe just a little forward thinking is a good thing.
As for was it easy to predict that the customer would want more values in the future? Yes it was, but "someone else can do that later" won out.
I guess I saw it as a waste of time for Twitter to just get it out with RoR and then have to rewrite everything once they became popular to support all of their users. Granted, there was no large scale usage of a RoR website at the time.
100% of the people that I have talked to have told me to take a personal day off, so I will do that In the mean time I am cleaning my suit and checking more about this BEIR position. Friends from the inside have told me that is like QC & Bioproduction mixed together into one :P
Comments
So says someone who can't get anything out the door. Then again, trying to make things scale is not the reason I am unable to launch.
Also, it's hard to rewrite your code to scale properly. However, there are many ways you can use IT to get really shitty code to scale in the mean time. Load balancers, better hardware, more machines, lots of options. You can get really far with a little bit of IT.
Twitter - RoR but if I'm sure everyone dreams of having those scalability issues.
Scalable solution - I go 'throw more hardware at it' every time if possible. Performance/scaling considerations in code generally make code less maintainable.
For instance, I'm working at a small company developing an in house ERP system. We add new features all the time, patch constantly. It's constantly engaging.
But far too often I find myself going back and fixing things that others had done for the sake of speed of release rather than done properly in the first place.
Sorry, it is nothing more than my own personal pet peeve.
It maybe faster to populate that combo box with 10 hard coded values than it is to create a list in the DB to populate it, along with the requisite management of said values, but after how many times being asked to add one more value is it correct to make it so the customer can manage the values themselves? (stupid example that came up recently, sometimes I wonder if my coworkers actually think some things through)
But yeah, it takes maybe five minutes to make that kind of change, but how many such five minute changes are there all around the system? A lot. If you do them all, it adds up to a lot of work. Doing it the stupidest fastest most copy-pastest no code-reuse way is the fastest way to get the job done. If the system gets the primary job done, then go with it. Your engineering brain won't like it, but that's the way to succeed in the software business. Just look at the rich guys. They all got there by rushing shitty software out the door that at least got the job done. And even though it's far from perfect, they beat the other guy. It is extremely rare that well engineered software is successful in the marketplace.
As for was it easy to predict that the customer would want more values in the future? Yes it was, but "someone else can do that later" won out.
I guess I saw it as a waste of time for Twitter to just get it out with RoR and then have to rewrite everything once they became popular to support all of their users. Granted, there was no large scale usage of a RoR website at the time.
In the mean time I am cleaning my suit and checking more about this BEIR position. Friends from the inside have told me that is like QC & Bioproduction mixed together into one :P