Fred is struggling to answer the basic Fizz Buzz questions. He is answering them averagely well and yet something about both; his handshake and his personality seems nervous and weak.

Half an hour into the interview Fred seems desperate. He is fumbling; lying and pushing hard to get to the right answer; his desperation to get selected clearly showing in every question he answers. Half way thought the interview I ask him a question which changes the course of the entire interview:

'Tell me three things that you find completely unacceptable in an organization. Three things or attributes that if we had; they would make you reject a job offer; even if we were to give you one'

Fred looks at me like I just dropped a dead rat on the table. He thinks hard; and yet he cannot seem to think of one thing that would make an organization not worth joining.

What Fred; like most programmers who cannot program; was doing dear reader; was applying for a job where the only criteria that would decide if he joins us; was the criteria of us selecting him. 

Put simply; he would join any organization that offered him a higher salary; and had an interview process; he could somehow manage to clear.

Most veteran builders; unlike Fred; realize that interviews are not a phenomenon where a interviewer sits on the other side of the table and asks difficult questions which have to be answered --- 'somehow'.

Most veteran builders around the world that I have worked with; and in particular interviewed; realize that the act of applying for a job; is almost like making friends or for that matter; even dating; where both parties involved have to mutually decide if a relationship would work out in the long run.

If you happen to take interviews dear reader; may I suggest; that besides asking technical questions; you also spend a few minutes driving the discussion towards finding out the level of interest the candidate genuinely has towards your organization:

1. What does he know about your organization?
2. How much time has he spent on your website and what does he like or not like about your website?
3. How many valid and interesting questions does he have about your organization?
4. How many valid and interesting question does he have about the work he would be doing?
5. Is he even interested in knowing or finding out about the culture of your organization and how he fits into  the whole picture?

And most importantly; does the candidate have preferences; opinions and a spine strong enough to understand; that of the many programming jobs out there not every job is meant to be 'his' dream job; or even the one that he accepts.

When hiring candidates; don't just look for people who meet your criteria. Hire candidates who themselves have strong criteria; other than salary; that they expect the companies they join; to meet.

Hire candidates who clear your interview with confidence and then have the confidence to turn the tables around and interview your organization.

Hire folks who understand that of the many job offers that they can get not every job is worth joining. Hire folks who take time to know your organization; then actively interview and hand pick your organization; much like your organization hand picks them.

I wish you good luck.

I'm a firm believer of building close allied relationships with every single client that you work with. Having said that; the art of building allied relationships in the war front is a tricky affair. Finding a true ally you are willing to trust and bet your professional life on; is even trickier.

At Multiplitaxion Inc; a client of ours who was into selling multi-functional devices; it was not an uncommon sight to see countless engineers scramble for cover every time a new client showed up.

The reason: every single engineer in the premise knew that the client could ask for any product feature and chances were; that the marketing folks would go out there and either say that the device driver we were building already supported the feature or it was a part of next release that would be out in the next fifteen days.

Then; armies of consultants would be hired to get things to move faster. Multiplitaxion Inc; built their projects based on lies; but more than the lies; what really came back to bite us was the fact that Multiplitaxion Inc saw the client as external entity who descended from the heavens above; told the development team what to do; and then we; like robots; pretty much went out there and did what they told us to do.

Even today; I see countless engineers; both young and veteran ones; take the whole 'the-word-of-the-client' way too seriously. Every month I interview countless engineers; who use insanely stupid and complex frameworks to solve insanely simple problems. Ask them why they picked the framework and chances are; that they will tell you that their client wanted them to use the framework.

One example of taking the client's word way too seriously; came in this blog as a comment on my post about getting rid of your systems and not logging every single requirement your client has.

For those of you know did not read the post; the one line simplified version of the post; is that you need to get rid of as many systems as you can and sensibly possible and get your developers talking to each other.

Harvey Kandola offers a rather thought provoking comment on the very idea of getting rid of systems.

He brings up a valid point:

Good post, but not convinced the advice from 37Signals is applicable. What would you say to your clients who want to log and track each Request? Would you tell them that "we do not log / have systems". I think not.

In the end, every organization is different, and needs to look at things from it's own perspective. Team dynamics are a major factor in how people adopt and use systems.

I've myself gone ahead and suggested in the past that every organization is different; so yes; there is validity in the point Harvey makes. Having said that Harvey's comment also brings up a rather interesting concept of asking why and checking on the basic premise of the comment.

Humor me; dear reader; and read on; even if you might disagree. If nothing else; I might end up giving you some food for thought.

So; assuming that you have moved to an truly agile (without a capital 'A') environment where you have a successful product being used by a couple of clients; and you totally believe that logging every single requirement in a 'system' is not the way to approach software development. Smooth, free flowing, verbal communication has done the trick for you and has got you more than one successful implementation.

It is then that a client shows up and tells you that they want to track and log each request. What is it that we as software development shops; entrepreneur; and even developers; find so criminally wrong about telling the client that - we do not log or have a system for that.

Remember; that each client is different; and your relationship with your client; is an allied relationship or a marriage of two organizations to get something constructive done; where most typically your clients are supposed to know what needs to be get done and you are supposed to know how to get it done.

It is a mutual relationship; based on equality and exchange of value with your talent and services.

Go down the path of putting the client on a raised pedestal as a superior species who is always right; and you will soon learn that the path does not have an end. Every now and then; every successful business out there pulls the plug and learns the art of saying 'no'.

Success Factors CEO; Lars Dalgaard pulls the plug and draws the line; at the idea of being nice. He explains:

I was in Boston once and one of our customers was very nasty to our employees. I made it extremely clear to him right then and there that if he continued that; that means we close the deal. We like closing deals.

37Signals does it by starting by saying no:

Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.

And what do you say to people who complain when you won't adopt their feature idea? Remind them why they like the app in the first place. "You like it because we say no. You like it because it doesn't do 100 other things. You like it because it doesn't try to please everyone all the time."

We at have work; in my current organization; have said 'no' to a process or a methodology that a client wanted us to follow more than once. 

There are millions of clients on this planet; not every client out there is 'your' client. If your organization; or you genuinely believe in an approach or process; have the courage to stand by it; and say no --- even if it means losing a client.

Now; go find your own answers; figure out what works for you and what does not.

The next time; you have a client; who wants every error logged in a system; and 'if' your organization genuinely believes doing so is a waste of time; try saying 'no' for a change. There is a high possibility that you client might thank you for it in the long run; and if you lose them; they were probably not 'your' client in the first place. Just in case; if that happens; go look for another client.

There are plenty out there and if you look hard enough you might find clients who you can form strong allied relationships with.

I wish you good luck.

As programmers we love the idea jumping up to build a new system at every given opportunity.

At Multiplitaxion Inc; I see a few young and budding managers attend a conference for a project management tool by a software development giant. They come back hugely serious; excited and amazed; much like babies who have found something new to explore and play with.

When I see them bubbling with excitement --- I cringe.

As programmers we have a tendency to get hugely excited about building something or putting a completely new system in place. Walk up to a programmer and tell him that you are having problems with people not applying for leaves in advance and chances are; he will tell you; you need a leave tracking system in place.

Tell a developer that you are trying to start a small library to encourage people to read books and chances are that he will tell you how badly you need a library tracking system.

To be honest; it is not just the excitement of building something new that gets the programmer within us excited. As geeks we love to also connect using familiar systems. The problem with having a whole lot of systems in your organization however; is that if you get make too many systems available to your builders and geeks; chances are that they will never connect and communicate at a human level.

Folks at 37Signals have interesting advice to give to people who are looking for a 'system' to track the feature requests. In their classic book; getting real; they explain why you should just forget your feature requests instead of trying to log them in a formal system:

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones.

Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

James Shore and Shane Warden come heavily on the simple idea of a bug tracking system in their book - the art of agile development. They explain:

Unless you're writing software by and for yourself, you will have to deal with at least one other person somewhere during the process. A grudging détente is not enough; you need to work together effectively. This means forming solid working relationships that are built on honesty, trust, cooperation, openness, and mutual respect.

You can’t force people to do this. The best your agile method can do is support these sorts of relationships. For example, one way to engender healthy interaction is to have people sit together and collaborate in pursuit of common goals.

It’s far easier, unfortunately, to craft your method in a way that discourages healthy relationships. An extreme example (sadly, one that actually happens) is forcing all developer communication with stakeholders to go through business analysts. As another example, a sure way to damage programmer / tester relationships is to require them to communicate solely through the bug-tracking system.

Ideally, your team will fix bugs as soon as they find them, before declaring a story "done done." Nobody’s perfect, though, and you will miss some bugs. Schedule these bugs with story cards, such as "Fix multiple-user editing bug." Schedule them as soon as possible to keep your code clean and reduce your need for bug-tracking software.

The point here; dear reader; is not to throw away all your systems of organization and turn into wild programmers who write random code. The point in fact; is all about is about letting go of access baggage and getting your basics facts right.

If you genuinely want your programmers to connect and communicate; first get rid of any excess 'systems' that you can possibly get rid of. Of course there will be some - like a version control system or the IDE in which you develop - that you cannot and should not get rid of; but reflect on and question the existence of every other system that you can see running in your organization.

Once you have done that; give your programmers opportunities to genuinely connected to each other verbally; their programming skills and their communication skills being the only two options left open to them and chances are; that they will use them both to the best of their abilities.

With no CYA systems in place and with free flow of information you will feel every ripple in your organizational pond and believe me dear reader; you will not need a fancy project management tool or an expensive bug tracker to find out what is going on. Honest.

At work; as a labs project; Kaushik Das; who is one of our seriously talented developers has been working on studying the SQL Server Schema --- just for the fun of it. To turn this learning into practical implementation instead of just theory; we decided; to build a web based administration console which users can use manage SQL server instances that they have access to using a web based administration console. This; is how eFORCE SQL DB Administrator was born.

Put simply; the first version of SQLDBAdmin by Kaushik; in it's scope and basic philosophy is pretty much like any other web based administration console for SQL server; one common example being - Microsoft Web Data Administrator.

We do realize that this problem has been solved multiple times before; and we also realize that as of today SQL DB Admin happens to be a 'me too' product; but what we believe makes SQL DB Admin worth giving a try are the following facts:

1. Looks and feels just like the SQL Server 2005 Database Management Studio - so there is very little learning-through-fiddling that needs to be done. 
2. It is free and open source; which means you can not just download it but actually modify the source code for your implementations if needed.
3. We will be working really hard to add new features to SQL DB Admin which might make it easy to do day-to-day administration tasks. Some examples include: scheduling a database backup, compressing a database, re-indexing a table. etc.

As of today you can grab a copy of the SQL DB Admin code base by visiting its codeplex site.

As a matter of fact; this is one of those projects that we just started for 'fun' and now that we have something that works; we are seriously looking at adding new features that give you; dear reader; reasons to download it and use it while comparing it with multiple other web based SQL server administrators that are out there.

If you; dear reader; have a task or a feature in mind that you or your database-administrators do regularly on SQL server administration front and you would like to perform the same tasks through a web based console; let us know about the feature and we will try out best to squeeze those features into the road map for SQL DB Administrator.

In the meantime; if you want to grab a copy of the latest code base and start using it in it's current beta stage; you can get a copy from the SQL DB Admin codeplex website.

We genuinely and sincerely hope that this product; makes your life; as a database administrator; developer or anyone who has to manage multiple remote databases behind the firewall; just a little more easier. We will continue to add new features to SQL DB administrator and then blog about those features when we add them into the product.

Wish us luck.

More open source goodness coming soon.

Stay tuned.

Throughout my career; if there is one thing I have seen a lot in the software development world; it is; programmers who cannot program pretending and advertising that they are the alpha geeks of the millennium.

When I was a young and budding programmer; brimming with dreams and confidence; I walked the world of software development assuming only three kinds of people existed in the world of software development:

1. Alpha-geeks who were kick-ass programmers making huge dents in the universe with their code.
2. Passionate programmers who knew how much they sucked and were on the life-long path of learning how to become kick-ass programmers.
3. Programmers who could not program but were busy pretending they were alpha-geeks.

Then; years later; while consulting for a client; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; I met Jack; and I realized; that I was; dear reader; so very wrong; in my assumptions about people who exist in the software development world.

Jack was not a programmer.

In fact; he had done his major in philosophy.

When I first met Jack; the question that bothered me was simple: how the f@#k did Jack manage to join a software development firm?

In my first few weeks of working with him; I found my answer in the way Jack approached work; people and life. The guy was an interesting storyteller. He was almost a catalyst. To add to that; he was what I then started referring to as a --- 'contributor'.

During the first month of the project; Jack and spent a huge amount of time with me and the five person development team. He would read the requirements end to end and then talk about those requirements; so that we would not have to read them; he had valid questions on the flows we built; he engaged himself in usability testing; he tested the screens that we rolled out and pointed out valid bugs the official testing team was often not able to point out.

Our true surprise however; came when someone from the development team showed Jack how to write Ant scripts and we discovered that he was surprisingly good at it. Within a few days; we also had a build manager; taking up tasks which no developer wanted to take up.

Jack; dear reader;  was not writing a single line of code; but in a matter of three months; he had made himself very difficult to replace.

Steve Yegge brushes against the concept of a contributor in his post on a completely different topic; he explains:

Let's face it: there are a lot of professional programmers out there who realize they're not very good at it, and they still find ways to contribute.

If you're suddenly feeling out of your depth, and everyone appears to be running circles around you, what are your options? Well, you might discover you're good at project management, or people management, or UI design, or technical writing, or system administration, any number of other important things that "programmers" aren't necessarily any good at.

You'll start filling those niches (because there's always more work to do), and as soon as you find something you're good at, you'll probably migrate towards doing it full-time.

If you read between the lines; Steve's post might actually suggest that finding other ways to contribute when you discover that you are not a programmer; is not the best of things. You can actually hear a slight tone of sarcasm between the lines if you were to read them carefully. A few years ago; I would probably have agreed; but my experience with Jack; and a couple of other contributors I worked with after Jack; changed my opinion of this topic all together.

Yes; we don't need millions of non-programming contributors; but till date; I hold the opinion; that if you are a young and budding programmer; struggling with programming; not loving it; but you still feel passionately about being connected to the world of software development; you are much better off trying to morph into a contributor who contributes a host of things towards making the project a success and is a 'fun' guy to have on the project.

We do need a select few genuinely passionate 'contributors' around; much like we need good passionate programmers and at times; if you are genuinely passionate; we might not even care if you can write any code in the first place.

So stop trying to pretend you are the best programmer around; stop trying to climb in pecking order of your organization and desperately get promoted to the position of a manager; stop being a whiner; or a 501 programmer.

Find your niche and start making genuine contributions.

I wish you good luck.

Multiplitaxion Inc; a consultancy services organization I worked at years ago was an organization where Managers sat in ivory towers and gave strange; unclear instructions to engineers. Then when you started working; they would score a foul by emailing you about a completely disconnected topic; turning you from a programmer to a multi-tasking joker.

A classic example of unclear instructions happened at a project where we were building device drivers for a multi-functional device. This is when two young engineers fresh out of college were asked to --- 'map device codes to device names' halfway down the project.

What followed; as I watched in horror; was a long tale of errors and confusion; as these two young engineers; too scared to ask and get an intimidating response back from their managers; fumbled through the project document repository in an attempt to find the document that contained master device codes; device names and their mapping. Turns out; the repository had no such document.

After a couple of days of fumbling when the engineers asked for the device codes they were sent an email containing all the device codes that could exist in the system; leaving them to ask for all the device names and the mapping information between the two.

The entire cycle took three days of emailing back and forth after which they finally had everything they needed. It took more than five emails back and forth. One email had device codes; the other hand device names and three others had 'business logic' on how they could map device names to device codes.

My exposure to prickdom however; came when I needed additional specifications of the device and asked for the information I needed. Turns out; the manager was being bogged down with meetings and was too busy to respond to my email. What I got in response of the email I sent was an attachment. It was excel file containing device codes; names; the device specifications and the mapping between the three pieces of information.

As I scrolled through the email trail that had been forwarded to me; I learnt that the file had been sent by the client a couple of months ago.

A Gazillion questions filled my head as I glanced through the file:

1. Why did the manager not upload the file on the project repository and let everyone know?
2. Why did he not send the file to the two young and budding engineers when giving them their assignment?
3. Why did he actually take the pain to extract information out of the file; paste it in an email and send out only partial information over to the engineers; even when they explicitly asked for the information?

While this may sound like an extreme example of prickdom; I have seen managers around the world holding on to information and being highly reluctant to share it out; almost as if their job depends on what they know and what no-one else in the project team knows. Others spam the team with random information that the team does not need in the first place.

Joel Spolsky provides sound advice to young and budding managers when talking about the topic to human task switching. He explains:

On the individual level -- have you ever noticed that you can assign one job to one person, and they'll do a great job, but if you assign two jobs to that person, they won't really get anything done? They'll either do one job well and neglect the other, or they'll do both jobs so slowly you feel like slugs have more zip. That's because programming tasks take so long to task switch. I feel like when I have two programming projects on my plate at once, the task switch time is something like 6 hours. In an 8-hour day, that means multitasking reduces my productivity to 2 hours per day. Pretty dismal.

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they're going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.

At the end of the day it is not just about multitasking. If you call yourself a manager; a leader or whatever-it-is-that-you-call-yourself; it is your responsibility to see to it; that your fellow programmers have precise; compact and concise information to act on the tasks that you expect them to work on.

Do not start parallel threads of work; don't make them starve or look for information when it is readily available with you; and don't bombard them with more information than what is necessary.

If you are not comfortable leading from the front; the least you can do as a manager; dear reader; is get down from your ivory tower; develop a strong bonding with your team; show some empathy; stick around as a helper as they slog; and when they need information make the information available to them; without making them beg for it; or bogging them down with too much data or information that they do not need.

If you can just do that; you have probably taken your first step towards fearless project management without a lot of insecurity.

I wish you good luck on your way ahead.

Remember; if they are confused and lost as they develop; it probably is your fault.

Wikipedia defines Lorem ipsum in a website design proposal as - generally incomprehensible placeholder text allows viewers to focus on the visual elements, rather than the content.

Lipsum - the online Lorem Ipsum generator is bullish about the Lorem Ipsum history and future:

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.

It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

It was popularized in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

To be honest; Lipsum has a genuine reason to be bullish about Lorem Ipsum.

Graphic designers around the world have loved Lorem Ipsum for more then one generation.

Even today; I see countless graphic designers designing their site-layout using Lorem Ipsum; sending the designs out for review and then replacing them with real content as the project moves ahead.

Most graphic designers love Lorem Ipsum because it keeps them from having to work with those nasty business guys who are way too lazy to think about or give them genuine content upfront. Lorem Ipsum also shields the designers from those pesky programmers who make them fix their nasty HTMLs every time the designers try to work hand-in-hand with them.

The business folks love it because it allows them to walk up to a creative designer and say - 'I want a marketing website' - without having to worry about giving them any content or specifics before they start designing the website.

The programmers love it; because they can now develop their system without having to worry about synchronizing their development with the pretty-looking-screens.

Throw in a few stock photos; make pretty boxes; fill them up with Lorem Ipsum; and you are good to go. Life; for a designer; was never so beautiful before Lorem Ipsum showed up.

Put simply; at the end of the day; programmers love building ugly systems; graphic designers love building pretty boxes and business users love telling both programmers and graphic designers what they should do without feeling the need to take any real responsibility of the content or the message upfront. Lorem ipsum is a universal glue that makes this entire ecosystem function and makes all this possible. No wonder; we all love Lorem Ipsum.

Jason Fried at 37Signals however; has the courage to walk a different path and say no to Lorem Ipsum. He advices developers and designers to consider Lorem Ipsum their enemy; not their friend. He explains:

Lorem ipsum dolor has long been known as the designer’s best friend. We think it should be your enemy. Using lorem ipsum dolor reduces text-based content to a visual design element (a “shape” of text) instead of valuable information someone is going to have to enter and/or read.

We recommend that when you build out interfaces you use real and relevant words not “lorem ipsum” representative text. If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source. If it’s a name, type a real name. If it’s a city, type a real city. If it’s a password, and it’s repeated twice, type it twice.

The goal here is to get as close to the real customer experience as possible. Don’t abstract yourself from the real experience. Every layer removed pushes you further and further away from the actual customer experience.

Ben Hunt in his book; Save the Pixel; explains the same thing from the perspective of a veteran experienced web designer. He explains:

Design the content, not the box it comes in.

Use your pixels on things that communicate meaning. It used to be very common for web designers to make just templates – attractive or jazzy  containers which would have “content” added at a later time.

This is a fundamentally wrong approach, because it doesn't fulfill the designer's mission - facilitating communication. If you find yourself decorating the package, rather than crafting real, meaningful content, stop & ask: “Are these pixels best used here?”

You want the visitor to focus on the navigation & content as that's where the signposts are that point to the goals.

When you are designing the layout of a website; it is easy for you to get consumed by just the layout and not even think about the content or what the design is trying to communicate in the first place. Ben describes this concept rather articulately in his book - Save The Pixel. In his book he explains:

Design isn't Art. It's not about creating beautiful or thought-provoking things for the sake of it. Design is a discipline – creating communication with a purpose.

So the next time you head out to a Lorem Ipsum generator; try spending some more time on your content or your system and try to figure out the message that your application or website is trying to convey using your design. If you don't have a strong message your pretty boxes will not mean a thing.

Now; go think of a concrete message and decent amount of content or the system before you even open Photoshop.

This dear reader; is your chance to designing something meaningful.

Don't build pretty boxes with Lorem ipsum. Let your design be a part of your communication; what you want to say and what it is that you stand for.

I wish you good luck.

Sam at CodeOder.com asks a rather interesting question; asking which is much like opening a can of worms.

Sam's question seems like a simple question raised by an inquisitive mind; but scratch the surface of the question and you will realize it is not just a controversial question; but a question that can end up defining your character and life-style as a software developer. Sam questions:

We hear vague descriptions about project size tossed about all the time: Ruby on Rails is better for small projects. Java is for large projects. Skip the framework for small projects, but I recommend using one for large projects. What factors go into determining the "size" of a project?

Reflect on the question dear reader; and chances are that you might realize the problem in attempting to answer the question. You probably know this already. If you do not; ask anyone who has spent even a couple of years programming and estimating projects and he will tell you that:

1. Simply counting LOC or number of lines tells you nothing about the project size. It is a ridiculous metric.
2. Complexity is not indicative of largeness but just bad design.
3. Large team size is not an indication of a large project but just an indication of bad management.

And so; if we as programmers; are going to take every metric out there and thrash it against the wall; how are we to then; dear reader; measure which project is large and needs special attention and which project is small and can be built easily?

As a young and budding engineer at Multiplitaxion Inc; years ago; I was a part of countless meetings where my ideas were turned down with stereotype remarks like - yes-we-know-it-worked-for-your-project-but-our-project-is-really-large.

Attending countless number of those meetings taught me that the difference between a large project and a small project can be described using this rather funny code snippet on the sun java forum:

'Large Project' usually does not mean or do a thing other than give you a warm and fuzzy feeling of being involved in something complex deep down inside; and that dear reader; is not such a good thing.

No; seriously; if there is one thing years of programming; software development; and software management has taught me; it is that if you are working on a 'large' project you are doing something wrong.

Now; stop drooling over how large your project is; how huge a team you have; and how many lines of code you have to write. Go ahead; break your next so-called-large project down into smaller components and start hiring kickass developers  who can design each component like there were neatly cut pieces of diamonds.

I wish you good luck.