Software estimation continues to be a daunting process. Traditional plan driven approaches are being usurped by Agile-oriented methodologies. While the Agile Manifesto and Lean concepts are an important toolkit for the day-to-day management of a project, designed to help a team tune itself to its own capabilities and productivity over the life of the project, the application development estimation process still continues to be a dark art. Project Leadership must still answer to those more senior in the organization and those leaders must still answer to the market and investors. Often times, the question they ask is, ‘When will it be done?’ Ultimately, this becomes the seminal question for organizations eager to increase revenue through the marketing of new capabilities.

In this presentation, we’ve tried to provide some glue and distill some powerful concepts which can allow teams to rapidly enter negotiation with business customers regarding functionality, schedule, and cost. This seminar is focused on helping analysts, architects, and project managers become more confident using rapid and accurate estimation and planning skills. It serves to bridge the gap between Lean/Agile approaches and the more intensive forecasting needs of organizations of various sizes.

Some sample slides from the presentation are presented below. To get the full presentation or training, please feel free to contact us.

Objectives
The full seminar is focused on helping analysts, architects, and project managers become more confident using rapid and accurate estimation and planning skills. The seminar serves to bridge the gap between Lean/Agile approaches and the more intensive forecasting needs of organizations of various sizes. Participants will:
1. Understand the basic structure of a business requirement 2. Learn to listen for keywords in order to help organize the suite of requirements
3. Gain an appreciation for basic use cases and user stories
4. Obtain a basic overview for the use case point methodology for software estimation
5. Appreciate how to frame scope negotiation on a feature-by-feature
6. Appreciate the power of architecture and design in work-planning
7. Appreciate the power of what-if scenarios for estimates

Technorati Tags: Software estimation, project estimation, Joint requirements planning, use cases, user stories, agile, use case points, objectory, Gustav Karner, Barry Boehm, feature-driven development, service oriented architecture, iterative development

Now, traditionally some candidates are stumped by this question until we ask them the question a different way - that is, “can you discuss for us the philosophy behind the project management triangle?” The fundamental concept is this: a project’s main adjustable dimension are: schedule, cost, and scope (we tend to think about scope as a function of features and quality). The basic point is that one can be given the option to control any two of these dimensions, but the third dimension must be adjustable. From this starting point an interviewer can establish an incredibly rich set of questions and follow-ups in order to ascertain the experience, analytical acumen, and negotiation skills of a potential candidate.

Generally speaking, this philosophy is a sound an important academic principle.
In practice, however, 9 times out of ten, the number one “immovable” dimension for most initiatives is “schedule” with “cost” following close behind. That being the case, this is one of the key reasons that we tend to favor the Agile approach which tends to emphasize the capability of the team (leading to the effective scope acheivable) in the context of time-bound development.

Job Description
ALTERthought has a ground-floor opportunity for an Agile Coach/PM to work with technology and business leaders in order to advance ALTERthought’s innovative brand. In this role, the selected candidate will serve as a key client liaison and business partner, while managing the development and maintenance of a variety of client distributed systems and web applications, including Web 2.0 initiatives. This position requires someone to bring resourcefulness, experience and a passion for online technology solutions for start-up, emerging technology, and established Fortune 500 clientele. The candidate will also be involved in the future hiring of team members. Along with managing others, the candidate is expected to be an active part of the requirements gathering, solution planning, and quality assurance of our Clients’ solutions.

Responsibilities
- Work with Product Owner and members of the sprint team to ensure grooming of product backlog
- Work with Product Owner and members of the sprint team to plan releases
- Responsible for sprint planning and execution of sprints
- Responsible for removal/escalation of impediments
- Serves as a mentor & coach to members of the sprint team
- Responsible for reporting of risks, impediments, sprint and release progress to program team
- Mentoring of team members in various areas of Agile, serve as an Agile evangelist throughout the company
- Work with development managers to manage workload and availability of team members

Knowledge Areas
The ideal candidate will have experience in various programming environments and have a working project management/business analyst-level knowledge in one or more of the following platforms: (highly desired): Java, J2EE, Spring, Groovy on Grails, Ruby on Rails, AJAX, Jason, REST mySQL, Orace (nice-to-have): .NET/C#, SQL Server, Flash, Flex

- Bachelor’s degree in business, software engineering or computer science or other relevant combination of training and education
- CSM required, CSP and/or CST preferred
- One or more years acting as Scrum Master in a multi sprint team environment required, experience with building software for external customers preferred
- Strong knowledge of Scrum and XP principles and practices
- Desire to work in a co-located and open environment
- Three or more years project management experience preferred
- Experience using Agile project management tools
- Experience as a developer a big plus

Qualities
- Energetic and outgoing
- Highly Analytical, fact-based decision maker
- Ability to inspire and lead
- Champions change and effectively manage the implementation of new ideas.
- Supports and solicits input from team members at all levels within the organization.
- Communicates effectively.
- Ensures that we consistently deliver superior technical solutions.
- Interest in or experience with internet and startup businesses.
- Works well in a team environment.

ALTERthought is an Equal Opportunity Employer. For consideration, please “>contact us.

Full-time and contract benefits include a combination of paid holidays, sick days, personal days and vacation, premium health and dental insurance and a casual work environment.

About ALTERthought
ALTERthought is a management and technology consultancy that specializes in the engineering of large-scale distributed systems and is guided by a vision to help its clients win. ALTERthought TM marshals its Research, Development, & Management capabilities to combine innovation with precision management for the success of its clients.

Clients include the Global 2000, esteemed online brands, and leading mid-market companies. Since its inception in 1998, the engineering consultancy has collaborated with its clients to envision, architect, and deliver business results through intelligent technology solutions. ALTERthought is headquartered in Richmond, Virginia with offices in the National Capital Region, Research Triangle Park, and the New York Metropolitan Area.

ALTERthought’s software engineering and business consulting offerings include: full lifecycle software development, enterprise architectural re/engineering, mentoring, estimation and budgeting, project management, business strategy, business process engineering, information technology strategy, open source technologies, and digital security. For more information, visit the company’s website at: www.alterthought.com.

Responsibilities
The developer will serve as a team member and, where appropriate, mentor other associates in solutions to meet business needs. The ideal candidate will have experience working on agile teams developing software in a collaborative and iterative manner.

Knowledge Areas
The ideal candidate will have 2-6 years of experience in various programming environments as summarized by the following:

Summary

- Highly desired: Groovy/Grails, javascript frameworks (prototype, YUI, extjs, etc), mySQL
- Next Best: POJO, Spring, Ruby on Rails, AJAX, Jason, REST, JBOSS, Struts, WebWork, Oracle
- Nice-to-Have: Flash, Flex

Detail

- Bachelor’s degree in software engineering or computer science
- Strong architectural design and implementation skills
- A demonstrated ability to keep abreast of new technology
- Ability to establish and maintain effective working relationships with team members, managers and product specialists
- Ability to maintain own work flow and meet deadlines
- Ability to work in a fast-paced and dynamic environment
- Ability to respond to frequent pressure to meet deadlines when work speed and sustained accuracy are paramount
- Ability to respond to frequent demands of multiple customers (internal and external)
- Experience developing multi-tiered web applications on open source platforms utilizing Java/J2EE, Struts/Web Work, XML, SQL, AJAX, REST, SOAP, ESB, AOP, SOA, JavaScript, HTML and other related technologies and concepts
- Familiarity with open source frameworks and technologies such as JBOSS, Tomcat, MySQL, , Spring, Hibernate, SiteMesh, Alfresco, GWT, Maven, Mule, Linux, JUnit, Selenium, etc.
- Experience with Agile Development (SCRUM / Extreme Programming) practices, such as Test Driven Development, Continuous Integration, Iterative Development, and Pair Programming
- Ontology and Semantic Web technology experience, such as RDF, OWL, SPARQL, and Jena/SDB, is a big plus
Rules / Recommendation / Personalization engine experience is a plus
- Leader or contributor in open-source Java software is a big plus

Qualities

- Energetic and communicative
- Highly Analytical, fact-based decision maker
- Ability to inspire and lead
- Champions change and effectively manage the implementation of new ideas
- Supports and solicits input from team members at all levels within the organization
- Communicates effectively.
- Ensures that we consistently deliver superior technical solutions
- Interest in or experience with internet and startup businesses
- Works well in a team environment

ALTERthought is an Equal Opportunity Employer. To be considered for this position, please “>contact us.

Full-time and contract benefits include a combination of paid holidays, sick days, personal days and vacation, premium health and dental insurance and a casual work environment.

About ALTERthought
ALTERthought is a management and technology consultancy that specializes in the engineering of large-scale distributed systems and is guided by a vision to help its clients win. ALTERthought TM marshals its Research, Development, & Management capabilities to combine innovation with precision management for the success of its clients.

Clients include the Global 2000, esteemed online brands, and leading mid-market companies. Since its inception in 1998, the engineering consultancy has collaborated with its clients to envision, architect, and deliver business results through intelligent technology solutions. ALTERthought is headquartered in Richmond, Virginia with offices in the National Capital Region, Research Triangle Park, and the New York Metropolitan Area.

ALTERthought’s software engineering and business consulting offerings include: full lifecycle software development, enterprise architectural re/engineering, mentoring, estimation and budgeting, project management, business strategy, business process engineering, information technology strategy, open source technologies, and digital security. For more information, visit the company’s website at: www.alterthought.com.

]]> http://alterlabs.com/general/news/hiring-groovygrails-developers/feed/ http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/ http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comments Wed, 01 Aug 2007 22:37:12 +0000 sunjay Java Articles Budgeting Estimation Ruby/Rails General Groovy/Grails http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/ “Down goes Frazier (Ruby on Rails), down goes Frazier …” If the numbers we are tracking regarding an ongoing Enterprise Groovy/Grails initiative continue to pan out; as a business person, I will have a clear statement in the Rails/Grails debate: “I want all Grails, and I want it all the time.”


Our client is a Fortune 200 company for who we began an enterprise initiative on May 30, 2007. Thanks to our tool Planix and our friends and their framework, 6th Sense Analytics, we’ve been capturing projected and actual effort on this project.

For the work (user stories) completed to date (8 weeks/40%) of the project, the actual productivity of Grails is outperforming our estimate for J2EE, Java/Spring, and, yes, Rails. Qualitatively, it can also be argued that we’re also performing integration in an Grails/Java environment that may pose challenges for a Rails/Ruby/Integrated environment.

As is the case with most of our clientele, we agree not to publicly disclose the specifics of who they are/the nature of their project. So, we will be a bit limited in the amount of context we can provide. However, this occasional series of posts is largely a quantitative examination, so we look forward to sharing with you the data from our findings as the project progresses.

Why Do this ?

There is a lot of ongoing debate regarding the “speed of development” in various technologies; we simply wanted to add some data to that conversation and elevate beyond a developer/team’s “gut feel” about why a particular technology is more productive.

Why Groovy/Grails ?

We began this project on May 30, 2007. Prior to its start, we proposed and obtained approval to utilize Groovy on Grails from the client’s Architecture Team. Our reason for championing the use of Grails arose from a handful of factors. Chief among these factors, in no particular order, were:

(a) Our company history and charter to continually examine promising emerging technologies for the benefit of our clients
(b) The potential level-of-effort productivity boosts promised by a couple of Grails prototypes we completed
(c) The flexibility of Java-based technologies in tackling what we thought would prove to be a relatively complex systems integration initiative
(d) Java-based/EE technologies are the client’s preferred platforms; their teams and processes are organized around Java. We needed a technology that could help maximize the value of existing application investments while offering RAD capabilities

Why Should I Believe your estimates for the Other Technologies?

This is a fair point, but we’re pretty confident that the estimates are faithful and accurate to the respective platforms. We estimated the effort using our estimation and planning tool, Planix (written in Rails). We’ve used this tool for 5 years in various forms and have lived by its accuracy. The tool does embody a fair bit of our own methdologies; however, if you’re looking for objectivity, you should know that many of its principles are adopted from the giant, Gustav Karner, of the objectory whose work is adapted from *the* giant in software economics, Barry Boehm. A quick Google search will turn up plenty of studies on the proven accuracy of the Karner Use Case Point approach for a project. What we’ve done throughout our history is to benchmark the productivity of a variety of technologies to give businesses trade-off options when it comes to cost and schedule.



What are the Takeaways ?

Grails is the latest in our effort to benchmark technologies and their respective productivity; to date, Grails is showing itself to be slightly more productive than using Rails - to the tune of about 5.8%. As others have observed, we do believe Grails to be a “formidable challenger” to Rails .. and we’re gathering data to back up our claim. Yes, premature precision will get us in trouble and the sample size is characterized by 1 project that is 40% complete, but … well, you get the picture.

Stay tuned for more productivity analysis as well as technical analysis on the resulting code base.

Technorati Tags: Rails, Ruby, Ruby on Rails, Grails, Groovy, Groovy on Grails, Grails Productivity, Rails Productivity, Software economics, Barry Boehm, Gustav Karner

]]> http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/feed/ http://alterlabs.com/general/news/alterthought-sponsoring-barcamprdu/ http://alterlabs.com/general/news/alterthought-sponsoring-barcamprdu/#comments Tue, 24 Jul 2007 16:41:38 +0000 sunjay News Articles http://alterlabs.com/uncategorized/alterthought-sponsoring-barcamprdu/ Our team will be one of the sponsors for the 2007 edition of BarCamp in Raleigh-Durham to be held on August 4, 2007 at RedHat’s Raleigh campus. We were attendees last year and found the sessions to be invigorating and exciting - demonstrating the emerging vitality of the RDU area for emerging technology and business concepts. Fred Stutzman, a co-founder of Claim ID, is one of the coordinators of the event. You can find out how to help by visiting Fred’s blog.

About BarCamp -

“A Bar Camp is an unconference where people interested in a wide range of technologies come together to teach and learn. Unfamiliar with the un-conference format? Here’s the idea in a nutshell. Rather than having scheduled speakers, everyone pitches sessions the morning of the BarCamp. Those sessions are put on a schedule, and lots of little groups form for intense group learning. Everyone is expected to teach, to talk, to participate. Yeah, its different from a regular conference - but it works!

The idea of an unconference came together when people realized the best times they were having at conferences were the times between sessions - where people with like interests could meet ad hoc. The goal of BarCamp is to facilitate this type of interaction for an entire day. We supply the food, the space, the wireless, the projectors - you show up to teach and learn. “

Technorati Tags: BarCamp, ClaimID, Red Hat, ALTERthought, BarCampRDU, unconference

]]> http://alterlabs.com/general/news/alterthought-sponsoring-barcamprdu/feed/ http://alterlabs.com/general/news/ruby-on-rails-the-revolution/ http://alterlabs.com/general/news/ruby-on-rails-the-revolution/#comments Thu, 19 Jul 2007 20:04:42 +0000 sunjay News Articles Ruby/Rails http://alterlabs.com/uncategorized/ruby-on-rails-the-revolution/ I just jumped into the wayback machine and was inspired to think about technology adoption using a framework for the stages of political revolution - first shown to me by my high school History teacher and the school’s soccer coach, Larry Bosc. So, in addition to the way Geoffrey Moore canonized the technology maturation process in his Crossing the Chasm, I’ve been wondering if there is something to applying a template of political revolution to the way technologies (open source/standard technologies in particular) are born, ascend, and are ultimately usurped. Coach Bosc exposed us to Crane Brinton who published The Anatomy of Revolution in 1938 (reprinted in 1965).

“no government [technology movement] has ever fallen before attackers [rival technology] until it has lost control over its armed forces [engineers, bloggers, and evangelists] or lost the ability to use them effectively” - Crane Brinton


Its interesting to do a ‘find and replace’ on “regime, government, antiregime, radicals, extremist etc.” and substitute technology-related terms and movements in the summary I’ve excerpted below.


Its interesting to think about this model both from the perspective of the replacement/challenge of an ‘old line’ technology (.e.g J2EE, .NET) by an emergent technology (e.g. Rails). Its also interesting to perform the same ‘find and replace’ considering a split or schism within a particular technology movement (as has been hinted at in the Rails community and others before it)

I found a summary of Brinton’s work that allows this ‘find and replace’ on the Davis School District’s (Farmington, Utah) servers.

Perhaps its a stretch, but break out your favorite ‘find/replace’ tool and give it a shot yourself …

*The first stage of actual revolution comes with the growth of antiregime groups and the growth of their power to affect political thinking and behavior. Some critical problem arises which acts as a trigger for pent up dissatisfaction - such as whether the three estates should meet together or separately. The old regime can’t handle the problem. They lag in deciding or decide unpopularly. Rioting breaks out, but troops sent in to crush the rioters desert to the rioters side. The antiregime people take power relatively easily amidst widespread rejoicing. Popular expectations raise still further.

*Moderates initially wield power. They earlier had opposed the old regime but as critics rather than as revolutionaries. They want major reform rather than total revolution; to “fix” the government rather than replace it. The moderates tend to be motivated by morality, plurality, justice, and high ideals. Extremists accuse them of being weak and cowardly, and true enough, they are NOT ruthless enough to crush the extremists. The extremists begin to crush them.

*Extremists take over because they are more ruthless, purposeful, ideologically motivated, and are better organized than the moderates. In what Brinton likened to a fever during an illness, the extremists whip up revolution to a frenzy, throwing out everything old, forcing people to be “good” according to the new revolutionary standards. and punishing real or imagined enemies in a reign of terror which is intended to sweep away any potential threat to the revolution. In France, this stage came with Robespierre; in Iran, with Khomeini; and in Cambodia, with Pol Pot.

*A “Thermidor,” or calming-down period, ends the reign of terror. Brinton named Thermidor after the French Revolutionary month - the revolutionaries even threw out the old calendar - in which Robespierre fell. Every revolution has a Thermidor, which Brinton likened to a convalescence after a fever, because human nature can’t take the extremists and their revolutionary zeal and purity for too long. Power usually then falls into the hands of some opportunist/dictator, who restores order but NOT liberty, protection but not participation - in short, a Napoleon.

Just some food for thought …

Technorati Tags: crossing the chasm, Ruby on Rails, RoR, Anatomy of Revolution, Crane Brinton, Java, J2EE, .NET

]]> http://alterlabs.com/general/news/ruby-on-rails-the-revolution/feed/ http://alterlabs.com/general/articles/go-railers-in-the-midst/ http://alterlabs.com/general/articles/go-railers-in-the-midst/#comments Fri, 06 Jul 2007 01:37:55 +0000 sunjay Articles Ruby/Rails http://alterlabs.com/general/articles/go-railers-in-the-midst/ Dian Fossey would be proud. The comments and feedback I’ve received regarding my last post ranged from the contemplative: “excellent (though painful to read)…” to the vitriolic: “retarted.” Suffice it to say, I was impressed with the throng of Railers defending their (our) beloved framework (and more importantly “movement”) like Sigourney Weaver defending African Mountain Gorillas from hell-bound Poachers and Rawandan fatcat beauracrats. Apparently, I’ve offended. I’ve re-read that post a few times; its an order of magnitude less than a glove-slap as I see it. The funny thing is that post was one piece in a set of three attempting to ojectively analyze The Technology (Capital T - a compliment) from a business person’s (apparently an idiot business person’s) perspective. The others were:

Ruby on Rails as a Platform of Choice? The Case for Rails: examines why a business person *should* evangelize Rails as his or her chosen platform
Revenue on Ruby on Rails: examines our quantitative observations about productivity using the Rails framework

Two of the most interesting, legitimate, and constructive responses/rebuttals to both my post and the comments it engered that I’ve seen are the following:
From a noted Groovyist, Graeme Rocher: 5 More misconceptions about Grails
Graeme takes issue with the Rubyists and Railers denegrating Groovy/Grails.

“An interesting aspect of the above post however, was the reaction of Ruby/Rails users to the outrageous comment that Grails is a more realistic alternative in the enterprise. Some of the comments including even more classic misconceptions and knee-jerk reactions which I will address in this post..”

From Jon Dahl of Rail Spikes: Rails Develpers: Experts or Script Kiddies


Jon finds my statement regarding the mixed quality of developers in the Rails community to be interesting. Jon has the intellectual honesty to recognize that in a burgeoning movement such as Rails, its difficult and impossible to separate the technology from the enthusiasts as well as the poseurs. Both groups become ambassadors for the technolgy; and, given the groundswell in recognition for Ruby/Rails, the good, bad, and ugly come along with the territory.

“At the same time, there are a more and more mediocre Rails developers watering down the community. This wasn’t true two years ago, but as Rails grows, it attracts more and more newbies. There is nothing wrong with this; Rails is pretty welcoming to newbies, and today’s newbies are tomorrow’s experts.”

Jon does take issue with my statement that Rails encourages bad code and asserts the opposite. A position that I find to be accurate under the assumption that the developer is strong and legitimate. If not (see poseurs) business people tend to get apps that are problematic because Rails’ goodies and infrastructure can help cloak weak code as mediocre developers churn out features.

]]> http://alterlabs.com/general/articles/go-railers-in-the-midst/feed/ http://alterlabs.com/general/news/blasphemy-the-case-against-ruby-on-rails/ http://alterlabs.com/general/news/blasphemy-the-case-against-ruby-on-rails/#comments Tue, 03 Jul 2007 04:09:38 +0000 sunjay News Articles Ruby/Rails http://alterlabs.com/articles/blasphemy-the-case-against-ruby-on-rails/ In our last post I fawned over Ruby on Rails (RoR) like a schoolboy smitten by the new girl (let’s call her Ruby) at school. So, like the schoolboy’s heart wrenching realization that he mistook Ruby’s “hello, world” smile for a tender “will - you - be - my - boyfriend” countenance, I present a handful of potential RoR letdowns.

Skills Demand > Skills Supply …There appears to be considerably more demand for Rails programming than there are Rails programmers (irrespective of whether they are good programmers or mediocre ones). The theoretical speed of development and speed of enhancement (read: potential cost saving) as well as the trendiness (let’s face it) of Rails has inspired a legion of business visionaries to increase their demand for Rails programmers in order to get their own facebook-meets-amazon mind bender to market faster than the other guy.

Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 - $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours]

The Visual Basic effect … A corollary to the fact that “pretenders” are besieging the market is that Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases. Like Visual Basic in the mid/early 1990s, Rails allows non-computer scientists to put together seemingly impressive applications. However, as a project progresses or application matures the truth becomes clear: (1) Rails helps bad coders write unscalable, unmaintainable, unmentionable code faster, ergo (2) Rails helps organizations fail faster.

No Swiss Army Knife … Ruby on Rails was developed to do one thing and one thing well: help teams write web applications with user interfaces that perform basic operations on relational databases. Period. If you have complex processing needs such as message queuing, quantitative optimization, etc you’ll need to either (a) look somewhere else (b) write it into the framework (not likely as the shepherds of the framework are zealots and opinionated about protecting it from “unintended uses”) or (c) find a way to integrate with other technologies which support your business requirements.

No Throat to Choke and a Chasm to Cross … If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you’ve got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice. There are no/very few established vendors backing Rails at this point either from an implementation or education standpoint. This makes adoption of the technology and its ability to cross the technology chasm questionable. Rails is still early on the S-curve. It may make inroads into enterprise application environments the way Linux did through techie revolutionaries. However, for it to truly become a technology that is well understood, well-supported, and, consequently, well entrenched, it will need the backing of a behemoth or two. Perhaps RoR will gain the support of IBM or an equivalent, but the backing of a programming framework — at least on the surface — seems a heck of lot more pock-marked with landmines (variability in installations) than supporting and advancing the kernel of an operating system that has been in existence for decades.

The Java Defense … Perhaps the biggest reason not to choose Rails is, well, Java. The “old guard” Javaists are adapting. They may not be benefiting from the “hoola hoop” craze that is all things Ruby. However, they’re not taking the RoR attack lying down. In fact, in a very Zen-like fashion, they are borrowing from the “one thing well” manifesto of RoR to develop equivalents including Groovy on Grails, Trails, and the like (We’ll write about some quantitative benefits of these developments which we’ve seen first-hand in upcoming posts; suffice it to say, Groovy/Grails is proving itself to be a formidable challenger). In enterprise-friendly terms this means companies will be able to “maximize and enhance their existing Java technology investments.” And, with Java you get the Swiss army knife.

EDIT: For completeness and for the sake of those who did not have the time to navigate our blog, In a previous post, we examined the virtues of Ruby on Rails from a business perspective…and the potential economics of Rails in another post ….


Technorati Tags: crossing the chasm, Ruby on Rails, RoR, Rails productivity, technology adoption, Groovy, Grails, Trails, time to market,

]]> http://alterlabs.com/general/news/blasphemy-the-case-against-ruby-on-rails/feed/ http://alterlabs.com/general/articles/ruby-on-rails-as-a-platform-of-choice-the-case-for-rails/ http://alterlabs.com/general/articles/ruby-on-rails-as-a-platform-of-choice-the-case-for-rails/#comments Wed, 27 Jun 2007 20:19:31 +0000 sunjay Articles Budgeting Project Management Ruby/Rails http://alterlabs.com/ruby/ruby-on-rails-as-a-platform-of-choice-the-case-for-rails/ I’ll preface this post, by stating there are people infinitely more qualified in our company to discuss the technical merits of Ruby on Rails (RoR) as a framework choice. I write this post from the various perspectives of the “president,” “idea guy,” the sometimes “project manager,” and the “unresponsive stakeholder.”

There is much hullabaloo about RoR being the best thing to hit software development since the compiler (for the techies, the pun was not intended, but I’ll take it). While it may be something less revolutionary than compiler innovation, one thing is for sure RoR is currently — and promises to continue being — a Disruptive Technology.

So, Why Rails ?


From our first hand experience, these are some reasons why Rails should or could be your platform of choice.

This post is decidedly one-sided, I’ll explore why *not* to choose Rails in my next post.

There are a number of assumptions behind the reasons I am about to enumerate for choosing RoR. While we’ll save the play book for setting up a project team for other posts, I will say that a major assumption here is the quality of your team. That established, if you do assume a strong team while using development framework ‘A’ versus development framework ‘B,’ the benefits of Rails are as follows:

$$$$$ -You get stuff sooner. Its that simple. As a stakeholder, I’ve seen Rails teams turn features around in ½ the time as it would have taken them to do it using J2EE or .NET (see this post for a little comparison on development speed)

$$$ -You get more stuff sooner. Not only do you get your agreed upon set of features faster, but also you can expect to get incremental improvements and non-trivial enhancements sooner than using other platforms.

$$$ -You get to see stuff sooner. The underlying technology allows development teams to show business stakeholders features and changes in a much more expedient fashion (literally while looking over the developer’s shoulder). This makes the requirement clarification and refinement process much more real-time and iterative (read: Agile Manifesto-friendly).

$$ -You get goodies that come along for the ride. Rails is chock full of helpful technology that allows you, the business stakeholder, to present web applications that have really rich user interfaces. You’re able to present these rich interfaces to your user community without having to ask your team to undertake science projects (read: expensive) to get the equivalent functionality on other frameworks.

$$$ -It plays nicely with others. REST (pun intended) assured, with Rails as your platform choice, you’re able to integrate with other technologies. Rails is not only open source, but it strives valiantly to facilitate integration with data and other applications. These features of the framework come out-of-the box and are native to the thinking behind the development of Rails.

$$$ -Its Open. Like JBoss (J2EE Container) Rails is an open source project which means you don’t have to pay a nickel to use it. It also runs on things you can get free; like Linux.

$$$ -There is a fever. Similar to the manner in which Java ascended as a choice of web and enterprise development, Rails has zealots. The community that has sprung up around Rails is breathtaking. While this is an unscientific statement, it does seem that we are seeing the type of fervor, support, and evangelism that benefited Linus Torvalds’ Linux; and we all know, how that turned out.

Next up - The case against Rails …

Technorati Tags: software economics, Ruby on Rails, RoR, Rails productivity, software development costs, time to market,

]]> http://alterlabs.com/general/articles/ruby-on-rails-as-a-platform-of-choice-the-case-for-rails/feed/