Why New Technologies Move Your Product Faster?
Join the DZone community and get the full member experience.Join For Free
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
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.
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
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
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
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!
Published at DZone with permission of Alexander Beletsky, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.