I am a cloud application architect with 10 years' experience in software development in several languages, including Perl, Java and C#. I'm an Irishman living in Calgary, Canada. GitHub on @cubikca.
Location
Calgary, Canada
Education
BSc. Computing and Info Systems, Athabasca University
Getting things out is good. And constant bugs for 6 months is bearable to get the product out the door. What matters is what you do next. That technical debt has to be addressed. Once it's out the door, are you going to continue going at breakneck speed until the code craters and your developers quit in disgust? Or do you take the time to do it right before expanding further?
I pushed a product out the door before it was ready. I went crazy dealing with all the bugs. But, it had been waiting to be released for years, and it needed to be pushed out. We spent 3 years fixing it. After nearly 5 years, it's been modernized and fixed to the point where we can do further significant development on it. Thankfully we have leadership that understands the importance of addressing technical debt.
Do it right the first time. It's the only way. This is why I don't work in a competitive fast-paced startup.
So you like to research into different tools and techniques and come up with the best approach?. Done doesn't mean you introduce bugs, QA is must. Tech debts I can agree can grow and takes time to do refactoring.
I have seen project evolving from just a very simple CRUD into a highly configurable complex business critical logic as the requirements increased.
I am a cloud application architect with 10 years' experience in software development in several languages, including Perl, Java and C#. I'm an Irishman living in Calgary, Canada. GitHub on @cubikca.
Location
Calgary, Canada
Education
BSc. Computing and Info Systems, Athabasca University
Yes, I spend a good deal of my personal time doing research on tools and techniques. In addition to learning from mentors, talking to colleagues and keeping up with trends.
I try not to be a perfectionist, for practical reasons. But after that experience, I don't want to do things like that any more. Experience is a great motivator to do better :)
When I started working on this software, it was already a pretty complex beast. The company has grown since then, and the number of users has gone up considerably. The complexity creating by moving to a distributed system alone was a significant hurdle to get over and as you say, the business requirements are constantly evolving. But, as a result of this experience, we introduced a proper DevOps and improved our QA processes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Getting things out is good. And constant bugs for 6 months is bearable to get the product out the door. What matters is what you do next. That technical debt has to be addressed. Once it's out the door, are you going to continue going at breakneck speed until the code craters and your developers quit in disgust? Or do you take the time to do it right before expanding further?
I pushed a product out the door before it was ready. I went crazy dealing with all the bugs. But, it had been waiting to be released for years, and it needed to be pushed out. We spent 3 years fixing it. After nearly 5 years, it's been modernized and fixed to the point where we can do further significant development on it. Thankfully we have leadership that understands the importance of addressing technical debt.
Do it right the first time. It's the only way. This is why I don't work in a competitive fast-paced startup.
So you like to research into different tools and techniques and come up with the best approach?. Done doesn't mean you introduce bugs, QA is must. Tech debts I can agree can grow and takes time to do refactoring.
I have seen project evolving from just a very simple CRUD into a highly configurable complex business critical logic as the requirements increased.
Yes, I spend a good deal of my personal time doing research on tools and techniques. In addition to learning from mentors, talking to colleagues and keeping up with trends.
I try not to be a perfectionist, for practical reasons. But after that experience, I don't want to do things like that any more. Experience is a great motivator to do better :)
When I started working on this software, it was already a pretty complex beast. The company has grown since then, and the number of users has gone up considerably. The complexity creating by moving to a distributed system alone was a significant hurdle to get over and as you say, the business requirements are constantly evolving. But, as a result of this experience, we introduced a proper DevOps and improved our QA processes.