A few articles on n-teir architecture in .Net
Part 1:What is N-Tier Architecture?
Part 2:How to implement the Business Layer
Part 3:How to implement the Data Layer
LLBLGen::About n-tier development
N-Tier Applications and .NET
Plus:
See also:
StatSVN retrieves information from a Subversion repository and generates various reports describing the project development, e.g. timeline for the lines of code, contribution of each programmer etc. The current version of StatSVN creates a static set of HTML documents containing tables and chart images. StatSVN is open source software.
My coworker pointed me to this tool and I found it very useful.
Quick Sequence Diagram Editor is a tool for creating UML sequence diagrams from textual descriptions of objects and messages that follow a very easy syntax.
Below you may see a syntax example for Sequence Diagram shown in screenshot - it's very intuitive and easy to understand.
user:Actor
/order:Order
db:TicketDB
acc:Account
user:order.new()
order:return=db.reserve(date,count)
db:return=acc.debit(cost)
acc:return=db.bonus(date,count)
user:order.destroy
The tool supports actors, constructors, destructors, threads and on-diagram comments that can be used to represent conditions or loops.
Diagrams can be exported in PNG format.
Please choose a file named "sdedit-light_no_export_library.exe" to run the sdedit on a Windows Platform. The exe file is wrapped around a Java archive (you still need Java 5 or higher).)
SharpForge is an open source, .Net 2.0 project management web application. It's similar to SourceForge or CodePlex but for your own team or organization. It is available for you to download it and host anywhere you want or need to.
Features include
* Multi Portal
* Multi Project
* Subversion Administration
* Work Item Tracking
* Project Forums
* Release Management
* Subversion Wiki
* Browse Source Code
* News Feed Aggregation
Hey all
Here are some great tools that will help you diagnose problems and errors on your applications. Don’t leave home without them!
We all know that most problems start in the DataBase. SQL profiler will help you to locate excessive unnecessary DataBase access and long inefficient Queries. The tool itself comes with the installation of SQL server. Here is the MSDN article about how to use SQL Profiler
This baby is the best! Definitely one of my favorites. Fiddler is an Http Debugger where you can track and analyze all the Get and Post requests in many aspects such as Content, Timing and many more. Here is an MSDN article about how to use Fiddler. Download Fiddler here.
I Highly recommend using it. It can be a life saver sometime.
How will you know if your WebSite can handle the load?
WCAT to the rescue. WCAT will quickly allow you to simulate a fake massive load on you WebSite and provide you with statistics regarding the performance of your web application.
Check out this great WCAT tutorial by Alik Levines which explains how to use it and where to get it from.
Reference: Dev102
Recently I found out this great add-on for Visual Studio 2008 called PowerCommands. PowerCommands Extends the functionality of Visual Studio 2008 by adding some features which we all want built into Visual Studio. PowerCommands provides the following:
My favorite: Copy Reference, very useful indeed, and you all know it, just right click on the reference you want copied and select copy reference, now go to the another project and just paste that reference
* you can copy all the references by right clicking on references.
Another useful option is Collapse Projects, click on the solution and collapse all the projects at ounce. Very handy if you have a project loaded solution.
Email Code Snippet, I don’t know about how useful is it, but its cool :).
There is much more inside so just download PowerCommands here and find out all the other enhancements.
References: dev102
CVS is the grandfather of revision control systems. It was first released in 1986, and Google Code still hosts the original Usenet post announcing CVS. CVS is the de facto standard and is installed virtually everywhere. However, the code base isn’t as fully featured as SVN or other solutions.
The learning curve isn’t too steep for CVS, and it’s a very simple system for making sure files and revisions are kept up to date. While CVS may be an older technology, it’s still quite useful for any designer or developer for backing up and sharing files.
Tortoise CVS is a great client for CVS on Windows, and there are many different IDEs, such as Xcode (Mac), Eclipse, NetBeans and Emacs, that use CVS.
Subversion is probably the version control system with the widest adoption. Most open-source projects use Subversion as a repository because other larger projects, such as SourceForge, Apache, Python, Ruby and many others, use it as well. Google Code uses Subversion exclusively to distribute code.
Because of Subversion’s popularity, many different Subversion clients are available. If you’re a Windows user, Tortoise SVN is a great file browser for viewing, editing and modifying your Subversion code base. If you’re on a Mac, Versions is an elegant client that provides a “pleasant way to work with Subversion.” Xcode is Apple’s developer environment and Subversion client that ships with Leopard on a Mac.
Git is the new fast-rising star of version control systems. Initially developed by Linux kernel creator Linus Torvalds, Git has recently taken the Web development community by storm. Git offers a much different type of version control in that it’s a distributed version control system. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used.
Git prides itself on being a fast and efficient system, and many major open-source projects use Git to power their repositories; projects like:
GitHub has recently helped establish Git as a great version control system, providing a beautiful front end for many large projects, such as Rails and Prototype. However, Git isn’t as easy to pick up as CVS or SVN, so it’s much harder to use for a beginner.
Mercurial is another open-source distributed version control system, like Git. Mercurial was designed for larger projects, most likely outside the scope of designers and independent Web developers. That doesn’t mean that small development teams can’t or shouldn’t use it. Mercurial is extremely fast, and the creators built the software with performance as the most important feature. The name “mercurial” is an adjective that means “Relating to or having characteristics (eloquence, swiftness, cleverness) attributed to the god Mercury.”
Aside from being very fast and scalable, Mercurial is a much simpler system than Git, which is why it appeals to some developers. There aren’t as many functions to learn, and the functions are similar to those in other CVS systems. It also comes equipped with a stand-alone Web interface and extensive documentation on understanding Mercurial if you have been using another system.
Bazaar is yet another distributed version control system, like Mercurial and Git, that offers a very friendly user experience. It calls itself “Version control for human beings.” It supports many different types of workflows, from solo to centralized to decentralized, with many variations in between.
One of the main features of Bazaar is the fine-grained control you’ll have over the setup. As shown with the workflows, you can use it to fit almost any scenario of users and setups. This is a great revision control system for nearly any project because it’s so easy to modify. It’s also embeddable, so you can add it to existing projects.
Bazaar also has a strong community that maintains things like plug-ins and lots of third-party tools, such as GUI software to add a graphical interface to the system.
LibreSource is a Web portal used to manage collaborative projects. It’s based on Java/J2EE and is more a set of visual collaborative tools to help facilitate projects and teams. While the other systems discussed so far have been designed more on a “command line” level, LibreSource is centered more on tools that don’t have a big learning curve.
It has built-in features such as Wiki pages, forums, trackers, Synchronizers, Subversion repositories, files, download areas, drop boxes, forms, instant messaging and more. Think of LibreSource as a collaboration hub for project development.
LibreSource is perfect for the developer or designer who doesn’t want to learn lots of technical jargon and wants to focus more on communication with the project’s members. Just install the package and start collaborating, without facing much of a learning curve.
Monotone is the baby of the distributed revision control bunch. While many of Monotone’s peers focus on performance, Monotone places higher value on integrity than performance. In fact, it can take quite a bit of time for a new user of Monotone to simply download the initial repository due to the extensive validation and authentication required.
Monotone is fairly easy to learn if you’re familiar with CVS systems, and it can import previous CVS projects. However, it’s not quite as popular as other version control systems.
Những điểm nhấn trong cuộc thi
Đây chính là một cơ hội để xây dựng tương lai của Moblin. Các bạn sẽ có cơ hội để thoả thích sáng tạo những ứng dụng dành cho lĩnh vực giải trí và truyền thông vốn đang tạo nên sự phát triển mã nguồn mở dựa trên những thiết bị MID sử dụng hệ điều hành Linux. Bạn hãy truy cập vào trang web sau đây http://moblin.org/projectss.php để xem danh sách các loại ứng dụng đã có sẵn và những ứng dụng cần đựơc tạo ra. Những thí sinh phải nộp một bảng khái niệm về ứng dụng của mình trong đó các bạn phải giải thích và đưa ra cảm nhận về ứng dụng mà mình sáng tạo, giải thích lý do vì sao bạn cho rằng ứng dụng của bạn là thú vị đồng thời mô tả hoạt động của nó. Nhớ là đính kèm thêm những bức hình hay jpegs về ứng dụng của bạn một khi nó phát triển.
Từ ngày 10/09/2008 đến ngày 8/11/2008, các thí sinh sẽ phải nộp bảng khái niệm mô tả ứng dụng mà bạn làm ra. Vui lòng xem qua trang web www.moblin.org để biết thêm chi tiết về quy trình nộp thiết kế của bạn. Vòng sơ khảo (vòng đầu tiên) sẽ do Cộng đồng Mobin bình chọn ra top 10 ứng dụng hay nhất. Bất kỳ ai đăng ký đều có thể bình chọn những khái niệm ứng dụng được yêu thích nhất. Top 10 thí sinh thắng cuộc sẽ nhận đựơc USD 1000 và một chiếc máy MID để các thí sinh có thể sử dụng chiếc máy này phát triển bảng beta ứng dụng của mình. 10 thí sinh thắng cuộc trên cũng sẽ có được một chuyến tham quan ở Singapore (Do Tập đoàn Yahoo tài trợ). Những thí sinh thắng cuộc sẽ nhận được giải thưởng khi họ chấp nhận thi tiếp vòng chung kết và nộp bản ứng dụng beta chạy trên cád máy MID.
10 thí sinh thắng cuộc do cộng đồng bình chọn tiếp tục xây dựng, phát triển khái niệm của họ thành bản Beta (bản thử nghiệm). Hạn chót nộp bản thử nghiệm Beta là ngày 30/01/2009. Khâu đánh giá, tuyển chọn sẽ do những người am hiểu về công nghệ thông tin và mã nguồn mở trong nước phụ trách. Vào ngày 16/02/2009 sẽ công bố người đoạt giải nhất (đoạt giải vô địch) chọn ra từ 10 thí sinh thắng cuộc.
Những ứng dụng tham gia cuộc thi “Tốc độ của bạn” phải chạy trên chiếc máy MID và có khả năng xây dựng phát triển dựa trên Moblin.
Quy trình đánh giáViệc đánh giá dựa trên các tiêu chí sau : tính độc đáo, tính thẩm mỹ, cách thức sử dụng, yếu tố hấp dẫn, lôi cuốn người sử dụng. Cộng đồng sẽ bình chọn, và quyết định top 10 khái niệm mô tả ứng dụng được yêu thích. Thời gian bắt đầu bình chọn vào ngày 10/09/2008 và kết thúc bình chọn vào ngày 12/11/2008. Ngày 15/11/2008 sẽ ông bố Top 10 thí sinh được thắng cuộc tại @ Moblin.org.
Ngày 16/02/2009 những chuyên gia về IT trong nước sẽ chọn ra người giành giải vô địch từ 10 thí sinh trên.
Người đoạt giải vô địch (giải cao nhất) sẽ nhận được vé khứ hồi đi du lịch tới bất cứ nơi đâu trên thế giới để tham dự một sự kiện mã Nguồn Mở, bao gồm 1 tuần với đầy đủ tiện nghi.
10 người thắng cuộc được bầu chọn từ cộng đồng bỏ phiếu sẽ nhận được 1000 USD và một thiết bị di động vào ngày 30/11/2008. Những thí sinh trên được phép nhận giải thưởng khi họ đồng ý thi tiếp vòng chung kết và đồng ý nộp bản thử nghiệm beta ứng dụng của họ.
JDeodorant is an Eclipse plug-in that identifies and resolves design problems in software, known as bad smells.
- Feature Envy indicates that a method seems more interested in a class other than the one it actually is in.
- Type Checking is that all typed software entities should still have the same type after the refactoring, this issue often meets in Polymorphism, State/Strategy pattern.
With JDeodorant, it helps us to automatically detect those smells.
Resources:
- http://java.uom.gr/~jdeodorant/
- http://www.tabdee.ltd.uk/Software/Papers/Refactoring/Refactoring.html
Some sample analysis in sample Java project:
In this article: Can you call yourself an accomplished information technology employee? Find out by reading about the 30 IT skills you should have.
I noticed an article called "75 skills every man should master." It included some skills I have and some I don't. For example, I can tie a knot and hammer a nail, but frankly I can't recite a poem from memory, and bow ties still confuse me.
It was an interesting read and made me realize I could be more well-rounded than I am. To be honest, we all could be.
So in the spirit of personal growth, I developed a list of skills every IT person should have.
1. Be able to fix basic PC issues. These can be how to map a printer, back up files, or add a network card. You don't need to be an expert and understand how to overclock a CPU or hack the registry, but if you work in IT, people expect you to be able to do some things.
[ If you have IT staffers who aren't up to snuff, fire them. Learn how to do it right. ]
2. Work the help desk. Everyone, from the CIO to the senior architect, should be able to sit down at the help desk and answer the phones. Not only will you gain a new appreciation for the folks on the phones, but you will also teach them more about your process and avoid escalations in the future.
3. Do public speaking. At least once, you should present a topic to your peers. It can be as simple as a five-minute tutorial on how IM works, but being able to explain something and being comfortable enough to talk in front of a crowd is a skill you need to have. If you are nervous, partner with someone who is good at it, or do a roundtable. This way, if you get flustered, someone is there to cover for you.
4. Train someone. The best way to learn is to teach.
5. Listen more than you speak. I very rarely say something I didn't already know, but I often hear other people say things and think, "Darn, I wish I knew that last week."
6. Know basic networking. Whether you are a network engineer, a help desk technician, a business analyst, or a system administrator, you need to understand how networks work and simple troubleshooting. You should understand DNS and how to check it, as well as how to ping and trace-route machines.
7. Know basic system administration. Understand file permissions, access levels, and why machines talk to the domain controllers. You don't need to be an expert, but knowing the basics will avoid many headaches down the road.
8. Know how to take a network trace. Everyone in IT should be able to fire up wireshark, netmon, snoop, or some basic network capturing tool. You don't need to understand everything in it, but you should be able to capture it to send to a network engineer to examine.
9. Know the difference between latency and bandwidth. Latency is the amount of time to get a packet back and forth; bandwidth is the maximum amount of data a link can carry. They are related, but different. A link with high-bandwidth utilization can cause latency to go higher, but if the link isn't full, adding more bandwidth can't reduce latency.
10. Script. Everyone should be able to throw a script together to get quick results. That doesn't mean you're a programmer. Real programmers put in error messages, look for abnormal behavior, and document. You don't need to do that, but you should be able to put something together to remove lines, send e-mail, or copy files.
11. Back up. Before you do anything, for your own sake, back it up.
12. Test backups. If you haven't tested restoring it, it isn't really there. Trust me.
13. Document. None of the rest of us wants to have to figure out what you did. Write it down and put it in a location everyone can find. Even if it's obvious what you did or why you did it, write it down.
14. Read "The Cuckoo's Egg." I don't get a cut from Cliff Stoll (the author), but this is probably the best security book there is -- not because it is so technical, but because it isn't.
15. Work all night on a team project. No one likes to do this, but it's part of IT. Working through a hell project that requires an all-nighter to resolve stinks, but it builds very useful camaraderie by the time it is done.
16. Run cable. It looks easy, but it isn't. Plus, you will understand why installing a new server doesn't really take five minutes -- unless, of course, you just plug in both ends and let the cable fall all over the place. Don't do that -- do it right. Label all the cables (yes, both ends), and dress them nice and neat. This will save time when there's a problem because you'll be able to see what goes where.
17. You should know some energy rules of thumb. For example: A device consuming 3.5kW of electricity requires a ton of cooling to compensate for the heat. And I really do mean a ton, not merely "a lot." Note that 3.5kW is roughly what 15 to 20 fairly new 1U and 2U servers consume. One ton of cooling requires three 10-inch-round ducts to handle the air; 30 tons of air requires a duct measuring 80 by 20 inches. Thirty tons of air is a considerable amount.
18. Manage at least one project. This way, the next time the project manager asks you for a status, you'll understand why. Ideally, you will have already sent the status report because you knew it would be asked for.
19. Understand operating costs versus capital projects. Operating costs are the costs to run the business. Capital equipment is made of assets that can have their cost spread over a time period -- say, 36 months. Operating costs are sometimes better, sometimes worse. Know which one is better -- it can make a difference between a yes and no.
20. Learn the business processes. Being able to spot improvements in the way the business is run is a great technique for gaining points. You don't need to use fancy tools; just asking a few questions and using common sense will serve you well.
21. Don't be afraid to debate something you know is wrong. But also know when to stop arguing. It's a fine line between having a good idea and being a pain in the ass.
22. If you have to go to your boss with a problem, make sure you have at least one solution.
23. There is no such thing as a dumb question, so ask it ... once. Then write down the answer so that you don't have to ask it again. If you ask the same person the same question more than twice, you're an idiot (in their eyes).
24. Even if it takes you twice as long to figure something out on your own versus asking someone else, take the time to do it yourself. You'll remember it longer. If it takes more than twice as long, ask.
25. Learn how to speak without using acronyms.
26. IT managers: Listen to your people. They know more than you. If not, get rid of them and hire smarter people. If you think you are the smartest one, resign.
27. IT managers: If you know the answer, ask the right questions for someone else to get the solution; don't just give the answer. This is hard when you know what will bring the system back up quickly and everyone in the company is waiting for it, but it will pay off in the long run. After all, you won't always be available.
28. IT managers: The first time someone does something wrong, it's not a mistake -- it's a learning experience. The next time, though, give them hell. And remember: Every day is a chance for an employee to learn something else. Make sure they learn something valuable versus learning there's a better job out there.
29. IT managers: Always give people more work than you think they can handle. People will say you are unrealistic, but everyone needs something to complain about anyway, so make it easy. Plus, there's nothing worse than looking at the clock at 2 p.m. and thinking, "I've got nothing to do, but can't leave." This way, your employees won't have that dilemma.
30. IT managers: Square pegs go in square holes. If someone works well in a team but not so effectively on their own, keep them as part of a team.
© IDG 2007
Nghe mấy ông prồ thỉnh thoảng bắn một câu kiểu như "cậu muốn tiến xa trong cái nghiệp lập trình này thì phải rành design patterns". Thì đúng thế, ai chả biết. Design pattern vốn là tinh hoa của những người đi trước, đúc kết lại mà thành. Nhưng động vào thì ôi thôi, nhiều quá, biết rẽ lối nào đây?
Design Patterns: Elements of Reusable Object-Oriented Software là bí kíp vỡ lòng gối đầu giường của bất kì ai muốn theo học design pattern. Học đạo cần biết tên biết mặt sư tổ sư thúc sư huynh. Chính 4 sư tổ (the Gang of Four) của design pattern đã viết bí kíp này: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
Bí kíp nêu và miêu tả kĩ 23 chiêu. Như nhan đề bí kíp, những chiêu này dùng cho phong cách hướng đối tượng. Học đạo là học cái tinh thần, cái cốt lõi, sao cho dạt tới cảnh giới vô chiêu thắng hữu chiêu. Ai chưa thấm nhuần ý nghĩa của "vô chiêu", xin đọc (lại?) các siêu phẩm của Kim Dung hoặc bài nghiên cứu của Nguyễn Duy Chính. Nắm được tinh thần của design pattern rồi, thì hoàn toàn áp dụng được 23 chiêu trên vào những ngôn ngữ không hướng đối tượng, như C chẳng hạn.
23 chiêu vẫn chỉ là chiêu. Có thể tóm tắt tinh thần chúng lại thành 4 tiêu chí có quan hệ mật thiết với nhau:
Phần dưới bàn về 4 tiêu chí này. Design pattern là một phần của software engineering. Ai nghĩ bàn về software engineering mà không dính tí mã nào là kì khôi, thì thật sai lầm. Bởi vì về bản chất, software engineering không dạy cú pháp ngôn ngữ, mà dạy tinh thần (<- đã bảo là "đạo" mà lị).
Hãy nhớ lại các bài toán đặt làm nhân tử chung ở cấp 1, cấp 2. Refactor nghĩa là tìm những cái giống nhau đặt riêng ra ngoài.
Dấu hiệu cho thấy có thể refactor, là khi cứ phải cắt dán cả một khối mã. Để đỡ phải cắt dán trong cùng một chương trình, người ta nghĩ ra hàm hoặc class. Để đỡ phải cắt dán từ chương trình này sang chương trình kia, người ta nghĩ ra framework.
Chương trình có hàng chục chỗ cần vẽ tiêu đề cửa sổ, mà chỗ nào cũng phải dùng đến 10 dòng mới vẽ xong, thì sao không gom 10 dòng đó thành một hàm, lúc nào muốn vẽ chỉ cần 1 dòng gọi hàm?
Nếu vin cớ rằng project gấp quá không có thời gian refactor, thì nên bỏ việc lập trình vì nó không phù hợp với bạn. Làm phần mềm khó chứ không dễ, không phải thằng dở hơi có bản tính chụp giựt nào cũng tự dưng thành công. Mất có 1 tiếng để refactor mà lợi được cả nhiều ngày tháng sau mà còn không làm, thì bạn còn phải thức khuya dài dài để làm cho xong project.
Nếu vin cớ rằng xong project rồi hẵng refactor, thì quả là ngụy biện. Vì xong project rồi thì refactor để làm gì nữa? Bạn còn hứng thú để ngồi mò mẫm refactor nữa không? Những thư viện và framework có ý nghĩa thực tế đều là những thứ được sinh ra từ những project thực tế. Thư viện và framework do giáo sư tiến sĩ ngồi chơi xơi nước nghĩ ra chỉ đáng ném sọt rác.
Refactor mang lại quá nhiều cái lợi: mã ngắn gọn dễ hiểu, dễ bảo trì, dễ sửa, dễ sử dụng, dễ mở rộng v.v.
Nếu bạn nghĩ kế thừa (inheritance) chỉ đem lại cho bạn lợi ích "code reusable" thì đó mới chỉ là một nửa câu chuyện. Phần còn lại của câu chuyện là kế thừa tạo ra một họ các đối tượng có chung một giao diện (interface) thống nhất, từ đó thực hiện polimophism. Thông qua polimophism, client không cần (và không muốn) làm việc trực tiếp với object nào mà chỉ muốn làm việc với interface thôi. Nhờ đó mà hệ thống uyển chuyển hơn nhiều.
Chẳng hạn bưu điện là interface có chức năng gửi thư. Bạn là client. Có nhiều kiểu (type) chuyển thư: xe bò, xe gắn máy, ô tô, máy bay. Với tư cách là client, bạn chỉ muốn và chỉ cần quan tâm đến thằng interface, tức là bưu điện: cho thư (đã dán tem) vào thùng là thư được gửi đến nơi, mà không muốn quan tâm đến chuyện người ta dùng xe bò hay máy bay.
Khi cấu trúc inheritance (thừa kế) càng dài, thì hệ thống càng kém uyển chuyển. Khi B và C thừa kế A, thì giữa B-A và C-A có mối ràng buộc theo chiều dọc. Khi B muốn A thay đổi thì khó mà thay đổi A ngay, vì còn đụng đến C. Chẳng phải các văn bản thủ tục hành chính càng chồng chéo, thì nhân dân càng mệt hay sao? Chẳng phải người ta cũng muốn cải cách mà không thể cải cách ngay (hoặc chẳng thể?) hay sao?
Do đó, nên làm cho cây thừa kế càng thấp càng tốt, biến chiều dọc thành chiều ngang bằng cách dùng composition.
Nôm na là: nhờ được thằng hàng xóm cái gì, thì hãy nhờ ngay. Thoạt nghe thì rất vô trách nhiệm, nhưng hóa ra lại rất dân chủ. Các thể chế độc tài chẳng phải cái gì cũng ôm vào mình (điện, nước...), chẳng muốn nhả ra cái gì hay sao? Càng ôm thì càng đuối, đuội.
Thay vì ôm vào một cục, hãy san sẻ công việc ra.
Reference: Blog cong dong ve CNTTIf you want to lead a team, a company, an army, or a country, the primary problem you face is getting everyone moving in the same direction, which is really just a polite way of saying “getting people to do what you want.”
Think of it this way. As soon as your team consists of more than one person, you’re going to have different people with different agendas. They want different things than you want. If you’re a startup founder, you might want to make a lot of money quickly so you can retire early and spend the next couple of decades going to conferences for women bloggers. So you might spend most of your time driving around Sand Hill Road talking to VCs who might buy the company and flip it to Yahoo!. But Janice the Programmer, one of your employees, doesn’t care about selling out to Yahoo!, because she’s not going to make any money that way. What she cares about is writing code in the latest coolest new programming language, because it’s fun to learn a new thing. Meanwhile your CFO is entirely driven by the need to get out of the same cubicle he has been sharing with the system administrator, Trekkie Monster, and so he’s working up a new budget proposal that shows just how much money you would save by moving to larger office space that’s two minutes from his house, what a coincidence!
The problem of getting people to move in your direction (or, at least, the same direction) is not unique to startups, of course. It’s the same fundamental problem that a political leader faces when they get elected after promising to eliminate waste, corruption, and fraud in government. The mayor wants to make sure that it’s easy to get city approval of a new building project. The city building inspectors want to keep getting the bribes they have grown accustomed to.
And it’s the same problem that a military leader faces. They might want a team of soldiers to charge at the enemy, even when every individual soldier would really just rather cower behind a rock and let the others do the charging.
Here are three common approaches you might take:
You will certainly find other methods of management in the wild (there’s the exotic “Devil Wears Prada” Method, the Jihad Method, the Charismatic Cult Method, and the Lurch From One Method To Another Method) but over the next three days, I’m going to examine these three popular methods and explore their pros and cons.
Reference for more details: joelonsoftware
