Excellent read, and I totally agree.

There was a time where the QA manager at a company where i previously worked lined her cube walls with CD-R's with 'FAILED' written in Sharpie. Building my project on a clean box, compiling an msi file, and placing it on the CD-R was only the first step in getting an application into the production environment, and there were multiple pitfalls with overzealous non-developers buffeting me at every side. Did the code review from 10 co-developers get the thumbs up? Did I fill out all the needed paperwork, including deployment and release notes? Were there training documents? Did everything pass regression? Was the configuration manager in a good mood? Was there a roll back plan, with documentation and scripts, should something go wrong?

The last step for me was always the worst: the Saturday-Sunday 3AM deployment. Just me and the configuration manager, meticulously following each step in my release notes. If even one step was inaccurate, everything would be rolled back to be deployed next week. If the roll-back didn't work and somehow broke the system, people were fired.

Thanks for the memories! :-)

True quote from my experience: "I fixed the bug, it was simple, took me 5 minutes. Now comes the worse part: promoting to QA environment. It will take me all day!"

That definitely doesn't happen with Outsystems... ;-)

I have to disagree with this. Software reflects more about developer than the language/framework that is used to create it. In my experience all modern frameworks (like asp.net MVC, Rails) are good enough to build scalable and maintanable software. I never had issues with deployment in asp.net. If good practices are followed, good software can be written in all modern frameworks.

Kota -

The article isn't about whether or not someone can write good software in certain systems (you can). The article is about how all of these systems, over the last 10 years, have turned into environments where "DevOps" stuff like maintaining source control systems, build systems, continuous integrations systems, packaging systems, etc. etc. etc. is now the majority of a developer's time.

10 years ago, "deployment" for an ASP.NET application meant "copy/paste a directory, and maybe run a SQL script". Now, it is a highly complex process of building deployment packages and putting them into a system and working with that system's scripting language, and on and on and on. Instead of being an ASP.NET developer, you are now an ASP.NET, Gradle, Maven, Ant, Grunt, SASS, LESS, CoffeeScript, PowerShell developer.

J.Ja

But the question is , Do we really need to to use whatever is out there ? The only tools that we are using are SVN for source control and a testing framework. If a tool is not making your life easier , why use it ? Maybe I have not worked with sufficintly large systems to understand the context but my experience with mid to large scale enterprise solutions has been very good with minimal tool-set. 

Kota -

That is exactly the point of the article. Development teams have built up massive piles of "DevOps" tools trying to make life easier, and instead they make life harder, especially when applied to smaller projects.

But I do understand the reasons! I've worked on bigger projects where the old "copy/paste" of files to "deploy" was a disaster, there were hundreds of files in any deployment to stage, and missing one or putting it in the wrong place would cause problems... some wouldn't show for days or weeks. Those SQL upgrade scripts fell apart when minor differences in environments existed, or users had data that you did not expect. You had to push data from PROD to TEST to DEV every few weeks because of this (on one project I manage with OutSystems, it has been over a year since we did this, and while it is not perfect, we are still doing OK).

All of these tools have a purpose and fill a need... but it is a mess working with them. They are like certain medications, where the side effects are often just as bad as the disease they cure.

J.Ja

Allow me to disagree with kota :-), and pick something Justin said: "All of these tools have a purpose and fill a need...". And it's true, they fill the need for lifecycle management, requirements trace, team development, overall project management, etc. The problem is that many times these tools are built not really caring about the work of developers. Since they are side-tools with the purpose of side-tasks, which are not the main job of the developer, there isn't much investment in usability and productivity.

"Ok, let's ask the developer to fill in a form for each checkin" - seems reasonable.
"But he/she is a developer, so we don't need to pay much attention on the user interface". And suddenly every developer for each check-in has to open a webpage that takes ages to load, click 5 times, search for his project in a list of hundreds of projects not searcheable nor sorted in any order, and very quickly you will waste 90% of your time checking in, and 10% developing.

So, in my opinion, it IS a matter of tools and frameworks. The Outsystems 1-click philosophy makes all the difference. ;-)

Well, I think that the reason Outsystems makes life easier than pretty much every other SCM tool is the fact that Outsystems only provides basic SCM features. Essentially it only works as a repository, and litte else. That and the fact that it wraps everything into the deployment process.

This does make life easier 90% of the time, but when you need to push an emergency patch to production the fact that it doesn't support branching, for example, can make life pretty difficult too.

Edited: finished the broken sentence. :)

Yeah, that would definitely be my first priority for the Outsystems ALM backlog: requirement tracking and isolated promotion between environments.

Nice read. Indeed Outsystems is pretty awesome in most departments and will concentrate me mostly on code.

My wishlist for improvements is getting smaller each release, but there are still some point I love to see :)

HI All,
I am very new to this system but the good fact is if you get a system where you mostly need to concentrat on code and rest all will be managed by the system itself and the continueous improvements to the system itself to make it easy to use ..writing code here is just like you have lots of block and you just need to fix them in a perfect manner so that it produces a nice output (anyways use of brain is mandatory)..at last the conclussion is its awsome and i ahve seen the Beta 9 it roks.
Good going Keep it up.

One of our challenges at a company that promotes "lean manufacturing" is being able to deliver applications rapidly with fewer resources.  The Outsystems platform has been efficient in letting us do this.  Its nice having our delivery hangups on testing rather than coding.  This was definitely a great article.

Agreed with you all :)....

But I am as a beginner in outsystems struggled a lot to implement because of not having proper google help and also in the tutorials doen not provide real time examples to achieve work on this.

My suggestion is to maintain proper real time examples in our community so that everyone can make use of those.

Cheers,
Venkat

The Forge area has many 'real time' examples, either full applications or components that you can use in your applications and/or learn from.  Sure it would be great to have every question answered with a Google search like you can with .Net and Java projects, but if you take a little time to learn this environment you'll realize that almost everything you need is right here.

It's almost like as if someone should start a blog about OutSystems, or maybe even, who knows, write a book...