After some "umming" and "arrring" I decided I needed a new laptop - my 17" Rock is a beast, and rips stuff up, but it is heavy, and noisy. I asked some questions, read a lot of reviews, and decided finally that a MacBook Pro 15" should do the job - it had numerous glowing reviews, including from Windows biased developers like myself.

So I ordered my MacBook Pro from Apple, top of the line spec - and was very impressed by their speed of delivery - it was with me 2 days later. Damn efficient!

First Impressions

Opening the box I found a typical Apple experience (I own an iPhone too) ... plenty of designer packaging, pure minimalism, sleek, shiny and all around impressive.

The first surprise was the power adapter. It was very very light, and very compact. For a machine of this spec, it was ridiculously light. A really pleasant surprise, as the adapter is often what makes a laptop non-portable - lugging it around is no fun.

In a few minutes all was unpacked, and all was up and running. OSX was simple to setup and Bootcamp was setup with Vista not many minutes later.

The Screen

When ordering the MacBook Pro I was aware that the screen resolution wasn't the greatest, 1440 is a little limiting, but I was prepared to go with it for the saving in weight. The screen was actually superb quality, though it was very reflective, even for a gloss screen - mostly noticeable when I was watching some movies. The worst thing about the screen though was something I hadn't expected - it was Apple's equivalent to ClearType for smoothing fonts - it was terrible. I have seen this commented on before, as the Windows version of Safari uses the same renderer - I had just expected the one in OSX to be better. Pehaps on massive screens it is good, but on the MacBook screen it looked ugly. When I switched to Vista in Bootcamp (using ClearType) the quality was perfect, beautifully readable. I struggled on for a week, but never really got to like their font smoothing, every time I went back to Vista the difference just hit me.

Software

The general user experience of OSX was much as I remembered from the last time I used Macs (and that was a LONG time ago) - although OSX has gone through many evolutions, it was still very familiar.

I loved Expose (quick application switching) and the Dock (a much better variation of the Windows taskbar) in OSX - very user friendly. And Spaces on the Mac is simply brilliant - multiple desktops are SO much better implemented than on any Windows version I have ever seen.

I needed to be able to run Windows apps quickly without resorting to a reboot to Bootcamp, so at first I downloaded VMWare Fusion. Fusion was pretty good as a virtual machine manager, but it's integration with OSX (called Unity) I found to be clunky. After a day or two I decided to try Parallels, a similar product, and found it was nearly the same running a VM, but it's OSX integration (Coherence) was infinitely better than Fusion.

Parallels and Unity made it possible to run Windows apps inside OSX, but it still wasn't perfect. It was "fast enough" but not the speed I like in a development environment. Basic use of MS Office would have been fine - using VS was a little slow for my liking - for anything more than code tinkering I was going to have to reboot into Bootcamp and lose OSX.

I downloaded 10 or 15 open source and demo applications, but nothing was any better than the Windows equivalent.

The one killer app on the MacBook though was a surprise to me - Front Row. Front Row is like Windows Media Centre, a full screen media experience, play music, TV, movies, or whatever ... but the killer part of the application was that Apple shipped a remote control with the MacBook - one press on "start" and the screen faded to black and let me get straight to the media. A brilliant idea- and I seriously considered this when I was deciding if the MacBook was for me - and I'm not really a media freak.

Keyboard Woes

The other thing I hadn't counted on was the keyboard. I guess I was expecting it to be better than other laptop keyboards I had owned (it was Apple after all), but I never really gelled with it. Firstly the key spacing, all that space wasted - they could have made bigger keys, or laid them out better.

Then  a peculiar quirk, as a developer I am used to using CTRL, ALT and SHIFT a lot, in various combinations - but on the MacBook keyboard these keys just sit in the wrong place for me, I sort of have to twist my thumbs to use them effectively, which was gonna lead to pain eventually. The MacBook function key was where CTRL should have been, and the ALT key was where a Windows key would normally have been. Of course I am sure I could have soldiered on with these issues and got used to the layout, but I have to use PC keyboards on a regular basis, a lot of different ones, and getting used to the MacBook and then switching would certainly have slowed me down - I type pretty fast, and I don't need the hassle. No Delete key, and odd key combos for Home, End, Page up and Page Down added to my woes.

And another quirk - the " and @ were reversed (with the " above the 2 and the @ above the '). This is the American keyboard layout, but on a UK machine. I don't know if I got sent a US machine, or they all come like that but it was confusing. I tried and failed miserably for days to figure out how to remap those the right way around - and while I am sure there is a way, it wasn't obvious!

The trackpad was a pain to get used to at first, and drag/drop was always a pain, but the multiple finger gestures it allowed were great, and using 2 fingers to scroll a window, or 4 to bring up Expose was absolutely brilliant.

The Pros and Cons

So I was faced with a decision, do I keep the MacBook or send it back?

On the plus side for the MacBook was:

• Build quality was superb
• Weight, amazingly light, and the PSU was phenomenal
• Front Row was da bomb!
• Power was pretty darn good (2.8 processor and 9600M graphics)
• It cost around the same as a similarly specced PC laptop, which would be heavier

But on the down side:

• Mac OSX didn't offer me anything I couldn't do on Vista (Expose and Dock excluded)
• OSX font smoothing
• The keyboard was driving me nuts
• The trackpad was a pain in OSX, but under Vista I never even figured out how to right click, and all the shortcuts I was used to in OSX only worked in OSX.

Conclusion

Eventually I decided to return the MacBook to Apple - it just wasn't for me. As a developer I want the fastest damn thing I can get my hands on - and that left me with the option of using the MacBook almost exclusively as a Windows machine. As a Windows laptop it is pretty impressive, but you lose all the nice parts of OSX (Expose, Dock, Front Row), and are left with a well built machine, with a cool logo, and a quirky trackpad and keyboard.

Maybe I didn't spend long enough with the MacBook - others think it is the best laptop ever for Windows development - I only had 6 days with it,  but had to make a choice.

I look forward to a future generation of MacBooks, because if they can sort out some of those minor annoying niggles, I'm sure I could get to like the MacBook.

So What Now?

For the moment I'm back to using my 17" monster. It's not exactly portable, but it is luggable. And I'm feeling more comfortable already.

I decided to see if Windows could be made a little friendlier, and managed to find Switcher as an alternative to Expose - it is a brilliant clone, and if anything is a little better. The one thing I miss is the 4 finger drag on the trackpad to bring it up.

And for a replacement for the Dock I found two Windows options that shined - RocketDock and ObjectDock. I went with RocketDock for the moment, and it has made Vista a little more usable - again if anything it is a little better than the OSX Dock.

New Laptop

I have a new laptop on the way, it's actually a gaming laptop, a fair bit heavier than the MacBook, a fair bit more powerful too. It has a higher resolution on a 15" screen which will be welcome, and it has a good old fashioned Clevo keyboard (which I know and love). The MacBook beats it on 9/10 features, but unfortunately the 1/10 is the bit that matters most to me.

I may get a much much lighter laptop for mobile stuff (I use a laptop mostly so I can change room in the house, or go in the garden), which leaves me with the best of both worlds, just not at the same time.

A while I had a problem with my old blog at goinsane, and as I was now posting regularly at devlicio.us I didn’t pay it too much attention. Recently I have had a few people contacting me about my old site not working, so I figured I best get it up and running properly.

Looking around at blog software, I went through the usual suspects including DasBlog which I used to use. Great piece of software that DasBlog is, I kept finding references to BlogEngine.Net so I thought I would give it a try.

The software itself was simplicity to get up and running, far easier than I remember it was with DasBlog, and a whole world of pain less that Community Server. Pretty much an FTP to my host, and I had a blog up and running.

After playing around a while I found a few things were annoying me, so I looked to get those sorted out.

Code Formatting

This has always been a problem, due to the peculiar way markup works, and due to various addins, I can never seem to get code quite the way I would like. On devlicio.us I have been using the formatter from manoli.net but this often has quirks.

BlogEngine.Net has a version of the manoli formatter built in as an extension (extensions are a really cool idea in BlogEngine), but it wasn’t quite working for me – sometimes my code formatted one way, sometimes another. It turns out that this has been mentioned a few times in various places, and it seems the built in extension is a little picky on how things are formatted.

After a bit of searching I came across SyntaxHighlighter, but the theme I had chosen to use doesn’t like <pre> tags too much. A little more searching and I came across an alternative SyntaxHighlighter for BlogEngine.Net on CodePlex. This one was much simpler to install – just copy over the .cs files to your extensions folder, replacing the built in formatter. And it looks great:

TinyMCE to FCKEditor

Now my next annoyance, TinyMCE is the chosen editor in BlogEngine.Net, and one of the things TinyMCE does badly is let you put in the tags to get the syntax highlighting working.

Luckily, it is pretty easy to replace the editor in BlogEngine.net, and so I searched around and found some pretty good instructions. Fifteen minutes later and my editor was replaced.

Conclusion

All in all, BlogEngine.Net has been a delight to setup, and although my main blog will remain at devlicio.us, I will now try and ensure I cross post to my own domain just to keep Google happy.

If you need to get a blog up and running on your own domain, you should certainly check BlogEngine.Net out

A while back I was blogging at http://blog.goinsane.co.uk, using DasBlog. At this time my host had some weird settings and I never quite got things the way I wanted.

The guys at devlicio.us kindly invited me to join them, and I was happy to join a very prestigious bunch of guys – so I moved my blog there. My old blog continued to remain on http://blog.goinsane.co.uk, until recently when I managed to trash it and lose all the posts – some of which I hadn’t copies to devlicio.us. It happens that this site had a fair bit of Google traffic previously, and I have had a few requests from people who got an annoying 404.

Last week I was playing with BlogEngine.Net and fancied getting it up and running – it turned out to be a really nice, friendly piece of software, and so soon my old blog was up and running – minus all the old posts unfortunately.

So I have re-posted some of the ones I consider less trivial and more useful, some of these have proved very popular reading in the past. From now I’ll keep both blogs running, that way my rants can be found more easily!

http://blog.goinsane.co.uk/blog/post/Good-Development-Practices-Basic-Reading-List.aspx

http://blog.goinsane.co.uk/blog/post/Measuring-Progress.aspx

http://blog.goinsane.co.uk/blog/post/Statistics-and-How-They-Lie.aspx

http://blog.goinsane.co.uk/blog/post/What-Determines-High-Quality-Code.aspx

http://blog.goinsane.co.uk/blog/post/The-Only-Certainty-is-Change.aspx

http://blog.goinsane.co.uk/blog/post/How-to-Make-Late-Software-Even-Later.aspx

It struck me that a good reading list is always welcome to find, and while I suspect most of these books are not entirely new to you, I thought it a good idea to list what I think is the basis of any good development library. Start with these books and you cannot go far wrong, what they teach will be valuable for many years to come.

The links go off to Amazon for information purposes, but I get no referrer fee or credits, so feel free to purchase where you find the best deal!

Well, OK I exaggerate slightly, it wasn't NHibernate that wasted most of my day, but the fact that we are having to use a slightly out of date version of 2.0 to allow us to use NHSearch.

NHibernate Search is a great piece of code, it abstracts Lucene.NET away from your application, and lets you pretty much pretend that you are dealing with NHibernate. However NHSearch has slipped a little in development behind the main NHibernate trunk.

So earlier today, one of our devs got a problem with his seemingly correct query:

Well, actually that query worked just fine, until you added a simple .SetMaxResults() to it ... at which point it threw an exception and told us that the id had been duplicated in the query:

System.Data.SqlClient.SqlException : The column 'articleid' was
specified multiple times for 'query'.
The column 'articleid' was specified multiple times for 'page'.

Of course this didn't look right. So I dropped it onto the NH users group on Google, and awaited someone far more knowledgeable to point out what I had done wrong. Tuna Toksöz promptly pointed out, somewhat less than helpfully, that this was probably fixed in the last two days. Of course Tuna thought he was being very helpful - unfortunately we were running a few versions behind the trunk due to NHSearch - so I couldn't get the latest version to see this bug disappear ... my only option was very loud cursing.

So with some to and fro, and some suggestions from Ayende and Fabio, I stumbled along trying to get something to work - and as per the last time I tried, I failed miserably to get all the NH components to compile against each other, NHSearch was still the limiting factor.

Eventually Tuna provided me with the HQL version of the query we were trying to do, which alleviated my initial problem, though in a less than perfect way. But, solve the problem it did, and so it will get into our code base on Monday, and probably be semi-replicated across other entities we need to query in similar ways. BIG thanks go to Tuna!

An even better result, it turns out that Ayende has NHSearch on his radar imminently (this weekend was mentioned), so I am really hopeful that I can get an up to date version of all my favourite components working in harmony again, I may even be able to put Rhino Commons back in and remove my awful home grown versions of Repository and UoW!

This has to be the biggest reason to go with a mature open-source project like NHibernate, apart from it being pretty much the market leader in it's field, it has possibly the best support network you could hope for.

For all those companies that worry that using an open-source component in their code will be risky due to lack of a "real company" backing it up, I can only say:

"that big company could never be half as effective or responsive as the community support that exists around projects like NHibernate, Castle, Moq, Rhino, xUnit, and all the other great open-source work on which I depend to help me deliver high quality software"

"Working software is the primary measure of progress"

Fundamentally, there is no more valid measure for progress, than the working software itself. This only leaves open to discussion, the definition of "working software".

Defining "Working Software"

The criterion for defining working software is obviously open to debate. A common definition is:

Software can be called "working software" when it meets a defined set of business requirements and can be demonstrated to do so through testing.

This is one reason why Agile processes put so much value on unit testing, these tests show very early on in the process that software is meeting business requirements, without the need to create a fully functional user testable application. These unit tests also allow demonstration at a fairly low level of granularity that code is meeting requirements, where a user facing application is dependent on too many factors to easily establish correctness.

So How Do We Measure Progress?

Based on this definition, our best way to measure progress and velocity on projects is to evaluate defined business requirements, against the code that is provided to meet those requirements.

Code that is written, but is not yet functional and passing tests cannot be considered progress until it has been completed to a level as defined above.

This then prioritises getting components of functionality completed early, rather than attempting to do all things simultaneously.

The traditional "waterfall" approach to software development is to spread large amounts of functional requirements out amongst large teams, for example assigning each piece of functionality to a team member with an expected delivery date measured in weeks or months. This leads to very long cycles for delivery of something correlating to "working software"

An Agile approach to the same problem is to focus the teams on only a small subset of that functionality, and to attempt to deliver it in a working and testable state in very short iterations. The degree of success with which they do this then becomes their "velocity". The velocity can then be used as a predictor of future success rates and therefore of future timescales. This also allows a "fail fast" mentality, where it is better to hit problems early on and resolve them, rather than delay all the problems for as long as possible down the development path.

Therefore, the best way of measuring success is to do one thing at a time, do it well, ensure it works, ensure it meets criteria, ensure it can be tested, and then to replicate the things that went right on the next piece of functionality, and eliminate the things that did not go so well.

Industry experience suggests that the design of metrics will encourage certain kinds of behaviour from the people being measured. The common phrase applied is "you get what you measure" (or "be careful what you wish for").

A Brief Explanation of Cyclomatic Complexity and Code Coverage

Cyclomatic complexity is a measure of the number of possible paths through a piece of code. This is a relatively easy measurement to make, and code analysis tools can give you this figure directly. As cyclomatic complexity is directly analogous to the number of paths through the code, it is also a direct count of the number of unit tests required as a minimum to test all the code paths.

• A cyclomatic complexity of 1-10 is a simple piece of code that is easily maintainable.
• A cyclomatic complexity of 11-20 is a moderately complex piece of code, that is relatively easy to maintain.
• A cyclomatic complexity of 21-50 would indicate either a highly complex or high risk piece of code. The functionality of the code observed indicates it is in no way complex, and therefore it must fall into the high risk category.
• A cyclomatic complexity of 51 and above indicates un-testable code, and a very high risk to the project.

Code coverage measures the number of paths through your code that had at least one execution when unit tests were run. It does not however give any real quality measure against the value of those tests, or the actual quality of those tests.

It is actually easier to get better coverage results from writing poor code. The poorer the quality of your code and of your tests, the easier it is to achieve high coverage figures.

Code quality is an abstract concept again, and can be defined may ways depending on how you perceive quality. A good discussion of the many aspects of code quality can be found on Wikipedia at http://en.wikipedia.org/wiki/Software_quality

Some general high level objectives for software quality could be considered to be:

• Conformance to requirements
• Scalability
• Correctness
• Completeness
• Absence of Bugs
• Fault tolerance
• Extensibility
• Maintainability
• Documentation

At a code quality level, some general good guidelines would be:

• Readability
  - Code should be simple to read, even without comments
  - Class, method, and variable names should be expressive and unambiguous
  - Functional intent should be easily understood
• Ease of Maintenance, Testing and Debugging
  The degree of effort required to maintain, test and debug an application is a strong indication of the quality of the code and architecture. As the great majority of the cost of an application is actually composed of these three activities, these should be primary considerations
• Low Complexity
  Complex code is rarely complex because the business functionality it implements is complex. Most software complexity comes through poorly designed and implemented code, over analysis of the problem, or adding additional functionality for requirements that do not yet exist.
• Low Resource Consumption
  Poorly written code will not take account of resource usage, for example it will not cache information it could cache, or it will create new objects when it did not need to. These issues lead to hard to maintain applications when deployed and used.

To achieve these objectives, some basic principles of development and design can be applied. These have been referenced elsewhere, but are repeated here for clarity:

• Single Responsibility Principle
  There should never be more than one reason for a class to change
• Open Closed Principle
  Software entities (classes, modules, methods) should be open for extension but closed for modification
• Liskov Substitution Principle
  Methods that use references to base classes should be able to use derived classes without knowing they are doing so
• Interface Segregation Principle
  Clients should not be forced to depend upon interfaces they do not use
• Dependency Inversion Principle
  High level modules should not depend upon low level modules, they should both depend upon abstractions
  Abstractions should not depend upon details, details should depend upon abstractions
• Principle of Least Surprise (sometimes known as Principle of Least Astonishment)
  The result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues
• Separation of Concerns
  The application should be broken into components that overlap in functionality as little as possible

An assessment of code against these core principles should give a developer a good basis for assessment of the quality of a code base.

I got an email at the end of last week from a developer asking about Agile development. It highlights a few problems with development in general, and with Agile as a "badge of honour" that are worth exploring. It deserved a fairly detailed reply, so excerts of the email follow:

I just came into an Agile project with some difficulties, they have stopped doing Agile development and gone back to a Waterfall approach. Coming into the project late, I saw numerous problems with the approach that are not helping.

It strikes me that developers rarely come onto a project and think how wonderful it is and how well it is running. This could be because they just have different ideas to everyone else, we all know developers are pretty opinionated, and believe they have the "right" answer to all the questions.

There is however a more likely reason, when you are close to a project, it is sometimes hard to see what is glaringly obvious to anyone with fresh eyes.

Agile can be daunting, you are fully exposed, you need to have Courage, you need to resist the urge to falling back to lines like "well we don't have written requirements", "it will be fixed in testing", "it isn't my code", and all the other Waterfall phrases.

Developers would be working on stories but things were not available to them as they had not been created yet - those items were in other stories

This sounds like a bad planning excercise. If you are using user stories, then it is the job of the developers to be involved in the planning of these, and to be able to assess up front what dependencies these stories have upon each other, and to properly break these down to more manageable, and more appropriate, stories.

I have seen similar problems, and it was generally caused by project managers deciding upon the priorities for things, and not listening to developer feedback (or not even including them). A good project manager is vital to a project to act as an "enabler", someone who can make things happen, can remove stumbling blocks, and can generally "grease the wheels". A bad project manager is the worst thing that can happen to a project.

Requirements changes by the business could cause certain functionality to have to be reworked significantly, causing a lot of problems, if the stakeholders changed their mind every time they saw something, more changes would be introduced. The more they saw, the more they wanted to change.

Well, Agile dictates (in so far as Agile dictates anything) that the only certainty in a project is that the requirements will change. We embrace change. Agile methodologies are all designed to allow change to happen as easily as possible, and to encourage change to be a core part of the driving process.

There is a point at which this can easily go wrong though, and again it comes down to either the wrong people in the planning excercise, or someone not listening.

Understanding change happens is only the first step.

You have to also explain to the business that change is inevitable, but it is certainly not free. The decision rests with them, but it is the job of the development team to properly evaluate requests and user stories to see what impact they will have on the project now, and into the future. Business users presented with an option to change, but no consequences of doing so, will of course choose change. When asked whether they want to make the change they think is needed, or do the other three user stories that were scheduled for this week instead, the choice becomes rather different. Agile encourages everyone in the process to become a stakeholder, but everyone also has to bear the cost of change.

Then you have to be able to think ahead and to design your system in such a way as to allow for change. This is a technical challenge, largely only obtained via experience, both of the development language and tools you are using, but also of the business team you are dealing with - how often do they change their minds, how often do they express things badly, how often do they get the wrong person to make the decision. In the sales game, you always want to be talking to the decision maker, becasue only they can give you the answer you need - make sure as a development team you are talking to the decision maker too.

A well designed architecture is fundamental to a successful project, and a key quality of a well designed architecture is the ability to make changes with relatively little impact upon other system components. Adding or modifying behaviour should not be a traumatic process - it may not be trivial either, but it should never be traumatic. I covered some of the aspects of this previously, and although that post was geared towards why Inversion of Control can benefit your code, it also deals with Robert C Martin's observations on a Rotting Design. Make no mistake, it is perfectly possible to start a greenfield project and have a rotting design from day one. It is also a large risk to any project that the once elegant code base rapidly slips into being a rotting design when time pressures are on, and people start taking shortcuts.

It is hard to know when it will be finished when things are always open to change

Agile methodologies do not say we have no delivery date, in fact almost to the contrary. Generally under an Agile project you should be able to deliver a working version of the software at any point in the development.

Admittedly the functionality present within that software will be largely restricted the earlier on in the process you decide to deliver, but 75% of functionality with a high quality code base is a lot better than 100% functionality which it is heavily bugged and fragile.

I often draw a triangle for clients, with Time, Quality, Functionality as the three points (Resources is often included here, but I ignore it for this purpose, Brooks Law usually applies by the point this matters). I tell them they can pick any two of those aspects and fix them, but that means the last one will have to vary. They cannot fix all three.

If Time is a critical deliverable, then you can choose to sacrifice Quality or Functionality (or both). The perfectionist in me says sacrifice Functionality, Quality is too precious to be the one to slip.

If Quality is a critical deliverable, then choose to slip Time or Functionality. The choice here only comes down to whether you want it fast or complete, or what combination of the two you want.

If Functionality is the key deliverable, then you can slip Time or Quality, and again I would say that Time has to slip, as Quality is too precious.

My personal opinion is therefore that Quality comes first, Functionality and Time are the things you can alter - but not only does this vary by project, but also by business circumstances. Sometimes it really is better to get to market with a low quality product, in the lowest possible time, with limited functionality (Twitter immediately comes to mind), just to steal a march on the opposition.

But what is really important, is that you express these aspects of development explicitly. If you are sacrificing quality because the business has asked for something unachievable, then let them know you are doing this, and make it an express design decision. If later on the business tells you the software is bugged to hell, you can point out when they took that decision to satisfy another need. If you need to take two more months because the business just changed the business model, then fine, but again make it an expressed and documented design decision.

Too many of these things get left as "assumptions" ... if you don't say otherwise, the business will assume a really high quality product, with massive functionality, in a very short timescale ... it isn't possible, so let them make the choice.

Repost: due to a switch in blogging software, this has been reposted

I'll start by quoting Brooks Law, as no doubt you expect me to:

Brooks's law is a principle in software development which says that "adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 book The Mythical Man-Month

The truth of this is blatantly obvious to anyone who has ever been involved in a project that was slipping its schedule. It is so blatantly obvious that The Mythical Man-Month is almost legendary in development circles largely due to that one brilliant observation.

Segmentation

The often suggested way to avoid Brook's Law biting your backside when you are faced with a project that is rapidly disappearing into the future is around segmentation, breaking your project into manageable chunks that can be developed in isolation. Teams can then take these chunks and develop while a core team is repsonsible for integration of their work. As Wikipedia correctly points out, when the segmentation is done poorly this can actually increase the time to deliver the project even more than just filling a single room with more developers - preventing developers on separate teams interacting easily, when they are actually working on common code is a near catastrophic mistake.

And now to my real point, correct segmentation can only work when there is a clear and clean architecture underlying the system upon which new developers and teams can easily add new functionality in complete and total isolation from each other, whilst still maintaining the integrity of the system.

One Common Vision

The architecture or framework is important in any project, it provides the one common point of reference that all developers have, a project can succeed or fail based solely on getting this part of the project right. Without this in place, all development work on the project is in real danger of producing an inconsistent and incohherent system, that at best will meet the majority of the business requirements but be totally unmaintainable over a period of time - a greenfield legacy system.

In a large project with multiple developers, and potentially multiple teams, the architecture is critical to the project success. Without this common vision teams will start going off at tangents, will duplicate work, and will spend more time trying to get their code to work nicely with their colleague's code than they ever will providing real business functionality.

And then Brook's Law not only hits you up the backside, it reverses back over you a few times just to be sure you are really suffering. Project managers, in a way that only project managers could do, ask for more developers to help integrate the code, and your descent into hell has begun.

Conclusion

So, if you do nothing else right on a project, get the fundamental architecture and framework right, early. Get a walking skeleton of all critical functionality running early against this architecture to prove it is right, and then ask the business to validate it. You will be amazed how much easier this will make things in the long run.