Architecture and framework choice team issue

Question

We are in the process of planning for a rewrite of one of our fundamental applications. It is web based, and we are locked into PHP. However it is not a web 2.0 site. It's closer to an enterprise application.

It's by no means simple. There are at least 2 main interfaces (I think there are 4, but that's another topic). It needs to be both highly configurable and highly customizable. I would expect between 50 and 200 installs per year, so ease of maintenance is a major concern.

So the problem comes in the architecture. I want to do a formal high level architecture first. Before anything else. After that, we would then either pick a suitable framework (one that fits the architecture) or pick one close and use it as a library set. I feel this methodology will guarantee a workable system in the long run (since at least the full architecture is considered)

However, the rest of the team wants to pick a framework (they want to use YII) first and skip the high level architecture completely. Their argument is that the framework did the high level architecture first and let's you "just start coding".

Basically, I think this is like putting the cart before the horse, or building your house with no foundation on top of a mud pit. I know this view is popular in the post-ROR days of rapid application development since more can get done faster. But I really fear that for a mission-critical core application, this is short-sighted at best (and negligent at worst).

I really fear we are going down the wrong path.

Management considers me as a senior developer. So technically I can overrule most of the others. But I am not above them, so in practice doing so would be bad. Mot to mention that there is a major language barrier (they speak Polish, I speak English).

And I think I should mention that I really don't like most RAD PHP frameworks. Not because they are bad by any means, but because they tend to (IMHO) enforce the mentality that architecture is not important since they do it for you. Not to mention that they typically want you to work their way (Rails is famous for that) rather than a way that makes sense for the project at hand. So I typically only use a framework as a set of libraries. Using the classes when they make sense, and building my own when the project requirements dictate so).

So my questions are as follows:

1. Am I right in my concern? Or are they right and am I just over-reacting?
2. If I am right, is there any advice on how to handle the situation?
3. How can I get the team on my side without causing a mutiny?

Answer 1

You may be interested in my recent blog post: Don't Put the Cart Before the Horse where I talk about how important it is to define the problem you're trying to solve before settling on any architecture choice.

As for getting the team on your side, there are multiple solutions because there are multiple reasons for resistance.

I recommend this book: Driving Technical Change: Why People On Your Team Don't Act On Good Ideas, and How to Convince Them They Should by Terrence Ryan. It's coming out soon, but you can order the beta e-book right away, and this applies to the final e-book when it's ready.

(disclaimer: I reviewed a draft of that book, and it's published by the same company who put out my own book.)

Answer 2

I'm having trouble picturing the high level architecture without any detailed info, but for what it's worth, this:

I want to do a formal high level architecture first. Before anything else

sounds pretty sane to me. Before picking a framework, it needs to be clear whether its structure is suitable for what you need to do, without having to bend it so far that it isn't that framework any more.

As to the how... I'm sure others are more qualified to answer that than I am. However, if time is of the essence, and the majority of the team wants to go the "let's get started right away" route, I would try to convince them to do at least a small number of architectural sessions first - and if it's just one or two afternoons.

If you don't really have authority over them (and even if you have), ask them to humour you for a limited amount of time. In my experience, architectural shortcomings and problems tend to come out pretty quickly once you get into it ("We need to do xyz. How do we do this in Framework X?"). An intensive session of simulating scenarios (and problems) might make people want to think twice about which platform they pick.

Answer 3

I'd say both of you are right. Considering the architecture is fine. But Architects often tend to overcomplicate things. It's not uncommon for developers to accuse Architects of living in an Ivory Tower, while they are down in the trenches. However, being in a trench is pretty low down to the ground, so developers often don't see forest for the trees, which can lead to equally undesirable ad-hoc architectures or island solutions that dont connect too well.

As for frameworks providing a higher level architecture already, well, yes. They do. But that doesn't mean it is the architecture you need. The things you will find in frameworks are (hopefully) modeled after established Design Patterns. Design Patterns are suggested solutions to common problems. If you do not need to solve these problems, you dont use a framework solving these either. It is the wrong choice. Now, that's rather generic, but you get the idea.

My advice would be not to abuse your senior developer position and force a decision onto them. Find a compromise. Involve them in the decision but expect them to discuss. I don't know the working environment at your place, but maybe consider adopting some agile processes, like Scrum. Maybe make some exploratory coding first with different frameworks to see what is better suit. It's better to fail with one framework early than to realize it's the wrong horse in the end.

Answer 4

The state you're in, you all know you need to build a 40-story building. But you never build a superstructure on sand. Getting a consensus just delays everything. Best approach is to get everyone to build a proof of concept in the shortest time possible with as many features as you can get from the expected product using the same baseline/deadline. Then get an independent review team to look at your approaches. Then make a decision. Frameworks and lattices are just support structures to your foundation.

Answer 5

Have any of the other developers deployed an application in YII similar to the one that needs building now? If not then you at least have some grounds to push back and a) find out what YII's strengths and weaknesses are (ask them to tell you) and b) how these measure up to the requirements of your project.

It's fine to go straight into coding if you are using a framework that you are already familiar which has a proven track record for building the type of application you want, but with a new framework (which is unfamiliar to your team) it absolutely makes sense to evaluate first, with at least a skeletal prototype, as part of your due diligence - especially if it's a commercial, mission critical application. Make sure it can meet every one of your must have business requirements.

In terms of pushing back, you can always ask the business to posit the question to the development team "tell us (justify) why we are using this framework to build our mission critical application".

Answer 6

You and your team disagree, but you're both right. You go write some documentation, and let them start cutting their teeth on a framework like CakePHP or whatever. Ideally, you should get some experience with more than one framework. This will enable you to make more educated choices about choosing your platform.

The reason that you want to do a bunch of design work first is very sound-- you need to know what you're doing before you do it. But it's also quite valid for other developers to start learning and using the frameworks. That knowledge will help you make decisions, and will also let your team start producing results more quickly.

I recommend that you don't stress too much about putting the cart before the horse. Think of the first couple of weeks as educating yourself, and prototyping, with the intent of throwing your early results away. The most difficult part of using a new framework or methodology is learning it, becoming proficient enough that you're mostly thinking about your application rather than the medium you're working in. Your people can be getting started on that while you contemplate design issues.

You may even be able to figure out some of the data model early, and let them start making the UI pages for those. Of course you'll need to change those as you refine the design, but how easy it is to make such changes is part of what makes a good framework.

The risk of prototyping is people's natural tendency to get too attached to something that's "working" and not want to discard it. But there are also risks with doing too much design work in the abstract without having anything concrete to interact with and spawn ideas.

I won't dive into a treatise on Waterfall vs. iterative. But I do recommend that you unleash your people's enthusiasm for diving right in, and let them get ahead of you on trying out and learning a couple of frameworks while you do design work. Then you can come together as a team, discuss your architecture, and have a more educated discussion together about which framework you want to use.