Thread

Humm.. Now i´m with a damn flashback like Windows Longhorn times…

“EE Longhorn?”

Ouch.

😉

Hey that does lead me to wonder what the Dereks’ and others might be referring to EE v.2.0 as?
Don’t all coding geeks have an in-house pet project name. Our last in-house project of a major consequence was

Codeword: “Rolling Thunder”

.
😉

What you think about:  “Codename: ExpectedEngine” ? 😛

What you think about:  “Codename: ExpectedEngine” ? 😛

Ahhh, wait I think I forgot about the propensity for in-house things to be labeled with a Pythonesque code word.
Maybe something like: “Spiny Norman” aka the 800’ long Giant Hedgehog as seen by the happy loony Pirahna brother Dinsdale.
Deep stuff.

“You hear that?!  We’re using code names.”

Maybe “Ex-summerEngine” ?

I know what I’m about to write won’t be popular since, in my own work, I hate it when someone throws that question at me but… I have also find it useful to address the question so it’s in that spirit (constructive criticism) that I’m raising the question.

There are basically two strategies to migrate to a new framework. One is the big bang, which is your current strategy, i.e. a full rewrite. The other one is gradual rewriting, while adding new features. For example, the migration takes place over the course of the entire 2.x development. The groundwork would be done in 2.0, but some stuff would remain old code (relying on a common database, of course). Migration continues in 2.1 alongside bug fixes. 2.2 adds new features and some more migration (one module at a time say), etc.

Both strategies are extremely frustrating because basically, as you said in your post, the underlying work is not glamorous and is frustrating but the big bang is typically choosen because it appears to be the easiest and fastest solution.
However in most projects the big bang causes you to loose competitiveness against other products… up to the point where a gradual migration actually makes more sens… despite its numerous shortcomings (and I know the shortcomings, and I know they appear unsurmountable until you have a real hard look at them).

So, after this introduction, my question is: are you sure the current strategy is the best one for the product and the community?

While you are working on the migration, other CMS are making progress feature-wise (MT has added custom fields, for example). More importantly 2.0 is not supposed to be feature-neutral, it is supposed to introduce the full commerce module which (if I read the forum posts) many people would consider a very worthy addition.

Please understand that I am not urging to change strategy. That would be presumptuous for me. But I’m asking have you considered all the consequences of the fact that you understimate the time it takes to migrate? Have you considered the alternative scenario?

Have you considered the alternative scenario?

Of course we have, numerous times. Note that we’ve continued to add functionality to EE gradually during 2.0’s development. As Jones stated 1.x has continued development so its not like we’ve ignored the community while 2.0 is inprogress. We’ve introduced numerous features and updates to the 1.x branch (that will also, therefore, be in 2.0). There isn’t a stand still or a lack of output from us.

Its the balance we’ve had to maintain while developing 2.0. To date 1.x is a strong product being adopted at all levels (like Change.gov and Ideo.com for example), sales have increased (not declined). Obviously 2.0 is taking longer than we would like but we feel our approach is the best solution. But we’re not bull headed either so if the situation changes or a better approach presents itself, we’ll certainly take it.

Also, just FYI, we’ve publicly stated that ecommerce is not launching with 2.0.

I think personally that the way it is being undertaken is the best. I don’t think that ExpressionEngine loses any competitiveness at all doing it this way as the development team are still keeping the 1.6.x branch up to date and in my mind 1.6.x as it stands now still kicks the pants off anything else out there. If it doesn’t do it out of the box (which isn’t a lot) then with a little bit of programming such as a plugin or extension you can usually get the system to do whatever you need.

I think (although I’m not a great programmer or anything) that gradually re-writing a whole code-base would be a lot lot harder to keep up with and probably more likely to be open to mistakes and errors.

The thing we have to understand is that they (the dev crew) have made their decision and it is their decision being their company and we just have to live with it whether we want to or not. Companies do make calls sometimes which don’t go down well with customers and even sometimes go wrong but history shows that everything ever done with ExpressionEngine has always always been good so I’m happy 😉

Just my two pennies worth though.

Best wishes,

Mark

I think (although I’m not a great programmer or anything) that gradually re-writing a whole code-base would be a lot lot harder to keep up with and probably more likely to be open to mistakes and errors.

Maybe not “more” open to mistakes and errors, but it does indeed encourage sloppiness.  “It works” is a very bad habit to form in programming, and it’s easy to hack things together so that they function without making real improvements.  Not to mention that it would make life difficult and frustrating for third parties, as the APIs and application code would be a never-ending moving target from one point release to the next.

Put in much better terms than I could make above 😉

I’m just impatient and hungry for more news.

Keep up the good work team 😊

I think (although I’m not a great programmer or anything) that gradually re-writing a whole code-base would be a lot lot harder to keep up with and probably more likely to be open to mistakes and errors.

My goal is raising the question was not to influence the development but to get re-assured that all the options had been considered so I’m happy with the answer. The following is not an attempt to influence the discussion, just to share experience.

I have worked mostly as a consultant for large organisations (e.g. IBM, EU Commission, Orange). In that environment one work always is in the middle of some sort of technical migration and my experience is that one almost always overestimate the costs and difficulty of a gradual migration and underestimate the cost and length of a big bang. I can think of very few exceptions to that rule.

Derek linked to an article describing just that choice between a rewrite from scratch and refactoring existing code. (and that article is linking to another good article on this subject by Joel Spolsky).

From the little bit of programming i know, i guess an inbetween version (gradual migration) is not at all an easy option for EE. CodeIgniter’s approach to Model-View-Control (MVC) probably doesn’t allow for just partially (or even easily) sliding EE into the CI framework or environment. CI however does make the base-layer very robust and therefore allows for a tall, maintainable building on top of that…

It’s not like re-arranging the deckchairs on ..^h^h (oops, wrong reference : )

Hey guys,

Not pushing but any update here? Just want to have a better idea if you think it will be 1-3 months, 3-6 months, or longer. It’s hard checking the site each day for an update…and actually physiologically proven that if people know how long to wait, they stay content for much longer.

Hope the coding is heating up as it gets colder and colder outside.