Why New Technologies Move Your Product Faster?
This summer my company e-conomic started new project with a working title SBA (Small Business Accounting). The project is about the creation of the product for small business owner, like consultants, web shops, freelancers etc. Since my company already had great expertise in that area the product vision and initial backlog of stories was already in place. Even more, we already had a product that does nearly the same but for a different target user - so, it was kind of natural to try to build SBA based on existing one. We started our journey having very ambitious plan in our mind meaning release in less than 6 month.
But to our great disappointment the progress for next 2 month appeared very low. We underestimated one thing - the existing product is a great but some of the underlying technologies were ill-suited for the new projects. Very simple things, like adding new custom form, UI changes, data access etc. were hard and unpleasant.
The legacy code, de-motivation and low progress.. were about to bury the project. Fortunately, the company were brave enough to change something on a fly. We went a very risky way, to build new product not based on old technologies, but almost from scratch. And as for me, that was great decision! So, somewhere in October we re-started the project.
What have we changed and how it went?
SVN => Git
I have posted earlier some my experience of starting to use Git in SVN-based organization. That time it was 2-3 people that tried to adopt that process, now it is only 2-3 who are not using it. We are thinking about moving to pure Git environment, but our deployment procedure slightly depends on SVN. As soon as we fix it, we can get rid of SVN completely.
You might argue, that changing source management tool is not exactly technological change and not affecting development velocity! But wait a minute.. How much time did you waste to resolve stupid tree conflicts? How much time you waste waiting for new branch, at the code freeze period? How many times your thrown away yours refactoring results, simply because you are not able to commit that now?
All of that factors are contra-productive. It could be not even seen from first sight, but Git improves the velocity simply by getting rid of annoying things that are natural to centralized source control management systems.
ASP.NET WebForms => ASP.NET MVC
Supporting WebForm’s code is a big mess. It’s is difficult to test, difficult to understand and to change. We had a bunch of custom controls that worked fine, but adopting them to something different is hard.
For the year I’m studding ASP.NET MVC and much inspired by it’s clear and powerful design. So, I was really happy we finally moved that direction.
We are using MVC in both modes: as for our web UI pages and for REST services. The same URL could produce both HTML or JSON response, depending on context. Having that, we are much flexible and not duplicate the code on pages and web services. MVC controllers are easy testable, Views are clean having only HTML with only few server side code snippets. Switch to ASP.NET MVC boosts us pretty much.
I think the adaption of new technology was really fast, even if we had some issues at the beginning they have been solved. I have to say that to use ASP.NET MVC we have to update production environment, namely upgrade in Windows 2008 with II7 which requires additional investment. But I think it’s only for good, cause having environment debt is the same as having technical debt in code.
Pure jQuery => Backbone.js
jQuery is the best javascript framework ever. It suites so nicely till the application is not getting to much big. As you getting out some imaginary “bounds” jQuery code get out of the control. Till that time we already had huge amount of .js files mixing out logic and UI stuff.
We were choosing between Knockout.js and Backbone.js and finally stopped at Backbone. Backbone.js introduce order in client-side code. It has clear separation of concerns for Models, Views, Controllers.. so we can say Backbone.js is MVC framework on client.
Having order is first step for productivity. The things are more predicable, read more fast to getting things done. Of cause, it takes a lot of effort to learn it. And no surprise some we still having some challenges caused by lack of expertise. But having Derick Bailey as our consultant making it better.
I would add that ASP.NET MVC and Backbone.js suits each other very nicely, since Backbone.js is REST oriented and ASP.NET MVC exposing REST in a right way.
Super.Tricky.NHibernate.Wrapper => ADO.NET
One of the pain-in-neck points of our application is data access. We have huge wrapper around the NHibernate framework. Words “Wrapper on NHibernate” could make someone sick, what if I say, “Wrapper on HHibernate, which is code generated”?
So, someone might treat that are making step back. But I don’t agree. Whatever things you can do in C# code, it is SQL only the language your Database can speak. Having a ORM’s are kind of having translator during the conversation with foreign guy. It works great as soon you speak simply, it’s getting worse than conversation going complicated, so translator hardly could translate everything you want to say. And of cause, it almost has no sense to have a translator, as soon if you can speak that language.
We are not using pure ADO.NET, it would be complicated. We have a tiny wrapper on that that basically run queries and returns result sets. It might seem harder, but I would say it’s very flexible. You can create what ever queries you need and map them what ever models you have. It works fine, it works fast. It is easy to test, since you no longer need NHibernate profiler to understand what’s wrong in you application, code just close to you.
After last Kiev ALT.NET meeting I understood we are not alone here. A lot of people start to understand that NHibernate becoming to heavyweight. New movement of MicroORM’s appeared, that combines power of SQL and functionality of mapping tables to objects. I want to believe that some MicroORM framework could be our next thing to adopt.
De-motivation => Obsession
It is not technological factor.. it is not even something I easy describe. Developers are taking responsibility by changing the things or advocating for some particular technology. You are no longer have excuse of bad quality because of legacy reasons. Sure, legacy still plays some role but impact is not so high.
Having a new technologies on board simply makes developers happier. Happy developer is obsessed developer, he is commited to success. He will work as much as he can to make good results.
With a consistent challenge, every day is no longer “another day in office”, but rather “yet another day on pirate ship”. It starts to smell start-up shop, that tried to get on market as soon as possible, adapting last available tools. The project now is not something I just had to do, but kind of pet project, where you trying things out and feel great if those things works.
That’s why in particular I think it is great to start from scratch (or near to scratch) one a year or something. Pick up last thing, learn them, adopt and build something valuable - it is nothing to compare with maintenance of 5 year old code.
New technologies moves you product faster!
This summer my company e-conomic started new project with a working title SBA (Small Business Accounting). The project is about the creation of the product for small business owner, like consultants, web shops, freelancers etc. Since my company already had great expertise in that area the product vision and initial backlog of stories was already in place. Even more, we already had a product that does nearly the same but for a different target user - so, it was kind of natural to try to build SBA based on existing one. We started our journey having very ambitious plan in our mind meaning release in less than 6 month.
But to our great disappointment the progress for next 2 month appeared very low. We underestimated one thing - the existing product is a great but some of the underlying technologies were ill-suited for the new projects. Very simple things, like adding new custom form, UI changes, data access etc. were hard and unpleasant.
The legacy code, de-motivation and low progress.. were about to bury the project. Fortunately, the company were brave enough to change something on a fly. We went a very risky way, to build new product not based on old technologies, but almost from scratch. And as for me, that was great decision! So, somewhere in October we re-started the project.
What have we changed and how it went?
SVN => Git
I have posted earlier some my experience of starting to use Git in SVN-based organization. That time it was 2-3 people that tried to adopt that process, now it is only 2-3 who are not using it. We are thinking about moving to pure Git environment, but our deployment procedure slightly depends on SVN. As soon as we fix it, we can get rid of SVN completely.
You might argue, that changing source management tool is not exactly technological change and not affecting development velocity! But wait a minute.. How much time did you waste to resolve stupid tree conflicts? How much time you waste waiting for new branch, at the code freeze period? How many times your thrown away yours refactoring results, simply because you are not able to commit that now?
All of that factors are contra-productive. It could be not even seen from first sight, but Git improves the velocity simply by getting rid of annoying things that are natural to centralized source control management systems.
ASP.NET WebForms => ASP.NET MVC
Supporting WebForm’s code is a big mess. It’s is difficult to test, difficult to understand and to change. We had a bunch of custom controls that worked fine, but adopting them to something different is hard.
For the year I’m studding ASP.NET MVC and much inspired by it’s clear and powerful design. So, I was really happy we finally moved that direction.
We are using MVC in both modes: as for our web UI pages and for REST services. The same URL could produce both HTML or JSON response, depending on context. Having that, we are much flexible and not duplicate the code on pages and web services. MVC controllers are easy testable, Views are clean having only HTML with only few server side code snippets. Switch to ASP.NET MVC boosts us pretty much.
I think the adaption of new technology was really fast, even if we had some issues at the beginning they have been solved. I have to say that to use ASP.NET MVC we have to update production environment, namely upgrade in Windows 2008 with II7 which requires additional investment. But I think it’s only for good, cause having environment debt is the same as having technical debt in code.
Pure jQuery => Backbone.js
jQuery is the best javascript framework ever. It suites so nicely till the application is not getting to much big. As you getting out some imaginary “bounds” jQuery code get out of the control. Till that time we already had huge amount of .js files mixing out logic and UI stuff.
We were choosing between Knockout.js and Backbone.js and finally stopped at Backbone. Backbone.js introduce order in client-side code. It has clear separation of concerns for Models, Views, Controllers.. so we can say Backbone.js is MVC framework on client.
Having order is first step for productivity. The things are more predicable, read more fast to getting things done. Of cause, it takes a lot of effort to learn it. And no surprise some we still having some challenges caused by lack of expertise. But having Derick Bailey as our consultant making it better.
I would add that ASP.NET MVC and Backbone.js suits each other very nicely, since Backbone.js is REST oriented and ASP.NET MVC exposing REST in a right way.
Super.Tricky.NHibernate.Wrapper => ADO.NET
One of the pain-in-neck points of our application is data access. We have huge wrapper around the NHibernate framework. Words “Wrapper on NHibernate” could make someone sick, what if I say, “Wrapper on HHibernate, which is code generated”?
So, someone might treat that are making step back. But I don’t agree. Whatever things you can do in C# code, it is SQL only the language your Database can speak. Having a ORM’s are kind of having translator during the conversation with foreign guy. It works great as soon you speak simply, it’s getting worse than conversation going complicated, so translator hardly could translate everything you want to say. And of cause, it almost has no sense to have a translator, as soon if you can speak that language.
We are not using pure ADO.NET, it would be complicated. We have a tiny wrapper on that that basically run queries and returns result sets. It might seem harder, but I would say it’s very flexible. You can create what ever queries you need and map them what ever models you have. It works fine, it works fast. It is easy to test, since you no longer need NHibernate profiler to understand what’s wrong in you application, code just close to you.
After last Kiev ALT.NET meeting I understood we are not alone here. A lot of people start to understand that NHibernate becoming to heavyweight. New movement of MicroORM’s appeared, that combines power of SQL and functionality of mapping tables to objects. I want to believe that some MicroORM framework could be our next thing to adopt.
De-motivation => Obsession
It is not technological factor.. it is not even something I easy describe. Developers are taking responsibility by changing the things or advocating for some particular technology. You are no longer have excuse of bad quality because of legacy reasons. Sure, legacy still plays some role but impact is not so high.
Having a new technologies on board simply makes developers happier. Happy developer is obsessed developer, he is commited to success. He will work as much as he can to make good results.
With a consistent challenge, every day is no longer “another day in office”, but rather “yet another day on pirate ship”. It starts to smell start-up shop, that tried to get on market as soon as possible, adapting last available tools. The project now is not something I just had to do, but kind of pet project, where you trying things out and feel great if those things works.
That’s why in particular I think it is great to start from scratch (or near to scratch) one a year or something. Pick up last thing, learn them, adopt and build something valuable - it is nothing to compare with maintenance of 5 year old code.
New technologies moves you product faster!