Subscribe: Joel on Software
Added By: Feedage Forager Feedage Grade B rated
Language: English
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Joel on Software

Joel on Software

Painless Software Management

Copyright: Copyright 1999-2016 Joel Spolsky.

Introducing HyperDev

31 May 2016 00:30:50 EST

One more thing… It’s been awhile since we launched a whole new product at Fog Creek Software (the last one was Trello, and that’s doing pretty well). Today we’re announcing the public beta of HyperDev, a developer playground for building full-stack web-apps fast. HyperDev is going to be the fastest way to bang out code and get it running on the internet. We want to eliminate 100% of the complicated administrative details around getting code up and running on a website. The best way to explain that is with a little tour. Step one. You go to Boom. Your new website is already running. You have your own private virtual machine (well, really it’s a container but you don’t have to care about that or know what that means) running on the internet at its own, custom URL which you can already give people and they can already go to it and see the simple code we started you out with. All that happened just because you went to Notice what you DIDN’T do. You didn’t make an account. You didn’t use Git. Or any version control, really. You didn’t deal with name servers. You didn’t sign up with a hosting provider. You didn’t provision a server. You didn’t install an operating system or a LAMP stack or Node or operating systems or anything. You didn’t configure the server. You didn’t figure out how to integrate and deploy your code. You just went to Try it now! What do you see in your browser? Well, you’re seeing a basic IDE. There’s a little button that says SHOW and when you click on that, another browser window opens up showing you your website as it appears to the world. Notice that we invented a unique name for you. Over there in the IDE, in the bottom left, you see some client side files. One of them is called index.html. You know what to do, right? Click on index.html and make a couple of changes to the text. Now here’s something that is already a little bit magic… As you type changes into the IDE, without saving, those changes are deploying to your new web server and we’re refreshing the web browser for you, so those changes are appearing almost instantly, both in your browser and for anyone else on the internet visiting your URL. Again, notice what you DIDN’T do: You didn’t hit a “save” button. You didn’t commit to Git. You didn’t push. You didn’t run a deployment script. You didn’t restart the web server. You didn’t refresh the page on your web browser. You just typed some changes and BOOM they appeared. OK, so far so good. That’s a little bit like jsFiddle or Stack Overflow snippets, right? NBD. But let’s look around the IDE some more. In the top left, you see some server side files. These are actual code that actually runs on the actual (virtual) server that we’re running for you. It’s running node. If you go into the server file you see a bunch of JavaScript. Now change something there, and watch your window over on the right. Magic again… the changes you are making to the server-side Javascript code are already deployed and they’re already showing up live in the web browser you’re pointing at your URL. Literally every change you make is instantly saved, uploaded to the server, the server is restarted with the new code, and your browser is refreshed, all within half a second. So now your server-side code changes are instantly deployed, and once again, notice that you didn’t: Save Do Git incantations Deploy Buy and configure a continuous integration solution Restart anything Send any SIGHUPs You just changed the code and it was already reflected on the live server. Now you’re starting to get the idea of HyperDev. It’s just a SUPER FAST way to get running code up on the internet without dealing with any administrative headaches that are not related to your code. Ok, now I think I know the next question you’re going to ask me. “Wait a minute,” you’re going to ask. “If I[...]

Stack Exchange Raises $40m

20 Jan 2015 12:00:37 EST

Today Stack Exchange is pleased to announce that we have raised $40 million, mostly from Andreessen Horowitz. Everybody wants to know what we’re going to do with all that money. First of all, of course we’re going to gold-plate the Aeron chairs in the office. Then we’re going to upgrade the game room, and we’re already sending lox platters to our highest-rep users. But I’ll get into that in a minute. First, let me catch everyone up on what’s happening at Stack Exchange. In 2008, Jeff Atwood and I set out to fix a problem for programmers. At the time, getting answers to programming questions online was super annoying. The answers that we needed were hidden behind paywalls, or buried in thousands of pages of stale forums. So we built Stack Overflow with a single-minded, compulsive, fanatical obsession with serving programmers with a better Q&A site. Everything about how Stack Overflow works today was designed to make programmers’ jobs easier. We let members vote up answers, so we can show you the best answer first. We don’t allow opinionated questions, because they descend into flame wars that don’t help people who need an answer right now. We have scrupulously avoided any commercialization of our editorial content, because we want to have a site that programmers can trust. Heck, we don’t even allow animated ads, even though they are totally standard on every other site on the Internet, because it would be disrespectful to programmers to strain their delicate eyes with a dancing monkey, and we can’t serve them 100% if we are distracting them with a monkey. That would only be serving them 98%. And we’re OBSESSED, so 98% is like, we might as well close this all down and go drive taxis in Las Vegas. Anyway, it worked! Entirely thanks to you. An insane number of developers stepped up to pass on their knowledge and help others. Stack Overflow quickly grew into the largest, most trusted repository of programming knowledge in the world. Quickly, Jeff and I discovered that serving programmers required more than just code-related questions, so we built Server Fault and Super User. And when that still didn’t satisfy your needs, we set up Stack Exchange so the community could create sites on new topics. Now when a programmer has to set up a server, or a PC, or a database, or Ubuntu, or an iPhone, they have a place to go to ask those questions that are full of the people who can actually help them do it. But you know how programmers are. They “have babies.”  Or “take pictures of babies.” So our users started building Stack Exchange sites on unrelated topics, like parenting and photography, because the programmers we were serving expected—nay, demanded!—a place as awesome as Stack Overflow to ask about baby feeding schedules and f-stops and whatnot. And we did such a good job of serving programmers that a few smart non-programmers looked at us and said, “Behold! I want that!” and we thought, hey!  What works for developers should work for a lot of other people, too, as long as they’re willing to think like developers, which is the best way to think. So, we decided that anybody who wants to get with the program is welcome to join in our plan. And these sites serve their own communities of, you know, bicycle mechanics, or what have you, and make the world safer for the Programmer Way Of Thinking and thus serve programmers by serving bicycle mechanics. In the five years since then, our users have built 133 communities. Stack Overflow is still the biggest. It reminds me of those medieval maps of the ancient world. The kind that shows a big bustling city (Jerusalem) smack dab in the middle, with a few smaller settlements around the periphery. (Please imagine Gregorian chamber music). View of JerusalemStack Overflow is the big city in the middle. Because the programmer-city worked so well, people wanted to ask questions about other subjects, so we let them build other Q&A villages in the catchment area of the programmer-city. Some of th[...]

Trello, Inc.

24 Jul 2014 22:03:27 EST

Hello? is this thing on? I’m not sure if I even know how to operate this “blog” device any more. It’s been a year since my last post. I’m retired from blogging, remember? Want to hear something funny? The only way I can post blog posts is by remote-desktopping into a carefully preserved Windows 7 machine which we keep in a server closet running a bizarrely messed-up old copy of CityDesk which I somehow hacked together and which only runs on that particular machine. The shame! I do need to fill you in on some exciting Trello News, though. As you no doubt know, Trello is the amazing visual project management system we developed at Fog Creek. Let me catch you up. As legend has it, back in yonder days, early twenty-oh-eleven, we launched a modest little initiative at Fog Creek to try to come up with new product ideas. We peeled off eight developers. The idea was that they would break into four teams. Two people each. Each team would work for a few months building a prototype or MVP for some product idea. Hopefully, at least one of those ideas would turn into something people wanted. One of those teams started working on the concept that became Trello. The idea seemed so good that we doubled that team to four developers. The more we played around with it, the better we liked it. Within nine months, it was starting to look good enough to go public with, so we launched Trello at TechCrunch Disrupt to great acclaim and immediately got our first batch of users. Over the next three years, Trello showed some real traction. The team grew to about 18 people, almost all in engineering. We did iPhone, iPad, Android, and Web versions. And Kindle. Oh and Android Wear.  The user base grew steadily to 4.6 million people. Zowie. Here are some things that surprised me: We’ve successfully made a non-developer product that actually appeals to civilians. We tried to avoid the software developer niche this time, and it worked. I think that’s because Trello is visual. The board / card metaphor makes every board instantly understandable, which seems to attract all types of users who traditionally had never found online project management to be useful or worth doing. It spreads like crazy. It’s a gas that expands to fill all available space. Somebody finds out about Trello from their reading group and adopts it at work; pretty soon their whole company has hundreds of Trello boards for everything from high level road maps to a list of snacks that need to be bought for the break room. People love it. We regularly monitor Twitter for mentions of Trello and the amount of positive sentiment out there is awe-inspiring. We launched something called Trello Business Class, which, for a small fee, provides all kinds of advanced administration features so that the larger organizations using Trello can manage it better, and Hey Presto, Trello was making money! Taco got big, tooIn the meantime, we started getting calls from investors. “Can we invest in Trello?” they asked. They were starting to notice that whenever they looked around their portfolio companies all they saw was Trello boards everywhere. We didn’t really need the money; Fog Creek is profitable and could afford to fund Trello development to profitability. And when we told the investors that they could take a minority, non-controlling stake in Fog Creek, we had to start explaining about our culture and our developer tools and our profit sharing plans and our free lunches and private offices and whatnot, and they got confused and said, “hmm, why don’t you keep all that, we just want to invest in Trello.” Now, we didn’t need the money, but we certainly like money. We had a bunch of ideas for ways we could make Trello grow faster and do all kinds of astonishing new features and hire sales and marketing teams to work on Trello Business Class. We  would have gotten around to all that eventually, but not as quickly as we could with a bit of folding mone[...]

Victory Lap for Ask Patents

22 Jul 2013 14:55:00 EST

There are a lot of people complaining about lousy software patents these days. I say, stop complaining, and start killing them. It took me about fifteen minutes to stop a crappy Microsoft patent from being approved. Got fifteen minutes? You can do it too. In a minute, I’ll tell you that story. But first, a little background. Software developers don’t actually invent very much. The number of actually novel, non-obvious inventions in the software industry that maybe, in some universe, deserve a government-granted monopoly is, perhaps, two. The other 40,000-odd software patents issued every year are mostly garbage that any working programmer could “invent” three times before breakfast. Most issued software patents aren’t “inventions” as most people understand that word. They’re just things that any first-year student learning Java should be able to do as a homework assignment in two hours. Nevertheless, a lot of companies large and small have figured out that patents are worth money, so they try to file as many as they possibly can. They figure they can generate a big pile of patents as an inexpensive byproduct of the R&D work they’re doing anyway, just by sending some lawyers around the halls to ask programmers what they’re working on, and then attempting to patent everything. Almost everything they find is either obvious or has been done before, so it shouldn’t be patentable, but they use some sneaky tricks to get these things through the patent office. The first technique is to try to make the language of the patent as confusing and obfuscated as possible. That actually makes it harder for a patent examiner to identify prior art or evaluate if the invention is obvious. A bonus side effect of writing an incomprehensible patent is that it works better as an infringement trap. Many patent owners, especially the troll types, don’t really want you to avoid their patent. Often they actually want you to infringe their patent, and then build a big business that relies on that infringement, and only then do they want you to find out about the patent, so you are in the worst possible legal position and can be extorted successfully. The harder the patent is to read, the more likely it will be inadvertently infringed. The second technique to getting bad software patents issued is to use a thesaurus. Often, software patent applicants make up new terms to describe things with perfectly good, existing names. A lot of examiners will search for prior art using, well, search tools. They have to; no single patent examiner can possibly be aware of more than (rounding to nearest whole number) 0% of the prior art which might have invalidated the application. Since patent examiners rely so much on keyword searches, when you submit your application, if you can change some of the keywords in your patent to be different than the words used everywhere else, you might get your patent through even when there’s blatant prior art, because by using weird, made-up words for things, you’ve made that prior art harder to find.  Now on to the third technique. Have you ever seen a patent application that appears ridiculously broad? (“Good lord, they’re trying to patent CARS!”). Here’s why. The applicant is deliberately overreaching, that is, striving to get the broadest possible patent knowing that the worst thing that can happen is that the patent examiner whittles their claims down to what they were entitled to patent anyway. Let me illustrate that as simply as I can. At the heart of a patent is a list of claims: the things you allege to have invented that you will get a monopoly on if your patent is accepted. An example might help. Imagine a simple application with these three claims: 1. A method of transportation2. The method of transportation in claim 1, wherein there is an engine connected to wheels3. The method of transportation in claim 2, wherein the engine runs on water Notice that claim 2 mentions claim [...]

Free as in Fortune Cookies

30 Apr 2013 15:42:55 EST

Trello has been out for less than two years and it’s been growing like wildfire. We recently hit 1.5 million members, of whom about 1/3 perform some action every month, and our MongoDB database now contains more than 70 million cards on 3.7 million boards. So the obvious question I get all the time is, “How exactly are you supposed to make money with that?” You may have noticed that Trello is free. Not “free trial,” not “freemium,” but just plain old free. Some people have justifiably wondered if it really makes sense to pay a dozen people, nestled in fancy offices with free lunch and espresso, to develop software that we have to pay Amazon cash money to host, while not actually charging for said software. Some have commented that this business model might actually be just a few fries short of a Happy Meal. What we really wanted to do was make a free product that helps millions of people, and then find some way to get paid by the 1% of those people who get the most value out of it. The 1% are delighted to pay. They actually email us asking if there is some way they can pay us. A fortune-cookie factory was so pleased with Trello they sent us a crate of tasty fortune cookies. Custom, Trello-color fortune cookies, with Trello fortunes inside. (Don’t tell the IRS, because that’s basically all we’ve made off of Trello to date, and I don’t think we declared it.) How do you identify the users who get the most value out of Trello? We thought any medium-to-large organization with lots of different Trello boards and many active Trello users must qualify. So then we tried to think of what kind of value-added stuff we could build and sell (for money) to organizations with lots of active users. Besides cookie dough. The most obvious things were features around security (permissions, backups, etc). Big organizations have people coming and going all the time, so they might benefit from tools that make it easy to add people to Trello en-masse, and tools to make sure that when people leave the organization, they're removed from any boards they should be removed from. The kind of stuff that’s helpful when tens or thousands of people inside an organization are all using Trello every day. We also added a feature called “observers,” which lets you add people to a board who might have permission to watch, vote, and comment, but who can’t add cards or move cards around. This is meant to give professional landscapers, developers, web designers, consultants, and fortune-cookie factories a way to let their paying customers peek in on the progress of their project without messing it up. It’s a classic example of a feature that is only useful when you’re in that class of Trello users who get the most value out of it, so paying should be a no-brainer. We bundled these features up and called them Trello Business Class. It's available today for $25 a month (per organization), or $200/year if you’d like to pay in advance. Of course, Trello itself is, and will remain, free, but starting today, we hope to actually make a little bit of walking-around money, too. In the future we'll continue to add free features to Trello (there is a lot of exciting stuff in the hopper)—anything that is a common feature, useful to anyone, will be free. We’ll also continue to develop new Business Class features that help large organizations manage Trello, and we may come up with other things to sell to people who are getting a lot of value out of Trello. In the meantime, we sure appreciate the cookies! Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people. [...]

The Patent Protection Racket

02 Apr 2013 13:31:45 EST

The fastest growing industry in the US right now, even during this time of slow economic growth, is probably the patent troll protection racket industry. Lawsuits surrounding software patents have more than tripled since 1999.

It’s a great business model.

Step one: buy a software patent. There are millions of them, and they’re all quite vague and impossible to understand.

Step two: FedEx a carefully crafted letter to a few thousand small software companies, iPhone app developers, and Internet startups. This is where it gets a tiny bit tricky, because the recipients of the letter need to think that it’s a threat to sue if they don’t pay up, but in court, the letter has to look like an invitation to license some exciting new technology. In other words it has to be just on this side of extortion.

Step three: wait patiently while a few thousand small software companies call their lawyers, and learn that it’s probably better just to pay off the troll, because even beginning to fight the thing using the legal system is going to cost a million dollars.

Step four: Profit!

What does this sound like? Yes, it’s a textbook case of a protection racket. It is organized crime, plain and simple. It is an abuse of the legal system, an abuse of the patent system, and a moral affront.

In the face of organized crime, civilized people don’t pay up. When you pay up, you’re funding the criminals, which makes you complicit in their next attacks. I know, you’re just trying to write a little app for the iPhone with in-app purchases, and you didn’t ask for this fight to be yours, but if you pay the trolls, giving them money and comfort to go after the next round of indie developers, you’re not just being “pragmatic,” you have actually gone over to the dark side. Sorry. Life is a bit hard sometimes, and sometimes you have to step up and fight fights that you never signed up for.

(image) Civilized people don’t pay up. They band together, and fight, and eliminate the problem. The EFF is launching a major initiative to reform the patent system. At Stack Exchange, we’re trying to help with Ask Patents, which will hopefully block a few bad patents before they get issued.

The Application Developers Alliance (of which I am currently serving as the chairman of the board) is also getting involved with a series of Developer Patent Summits, a nationwide tour of 15 cities, which will kick off a long term program to band together to fight patent trolls. Come to the summit in your city—I’ll be at the San Francisco event on April 9th—and find out what you can do to help.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Town Car Version Control

11 Mar 2013 20:34:31 EST

The team at Fog Creek is releasing a major new version of Kiln today. Kiln is a distributed version control system. One of the biggest new features is Kiln Harmony, which lets you operate on Kiln repositories using either Git or Mercurial. So you can push changes to a Kiln repo using Git and then pull them using Mercurial. This means that you never have to decide whether you want to use Git or Mercurial. Religious war: averted. But, I’m getting ahead of myself! For those of you that have been living under a rock, the single biggest change in developers’ lives in the last decade (besides Stack Overflow, natch) is Distributed Version Control. DVCS is such an important improvement over the previous generation of centralized version control (Subversion, CVS, etc.) that it’s a required upgrade, even though it’s honestly a bit harder to use. The popular DVCS options are Git and Mercurial. Both are open source. They are very, very similar in capabilities and operation; in fact, they are so similar that Kiln Harmony hides all the differences, so you can use any Git or Mercurial tool to work with any Kiln repository. If Git and Mercurial are open source, why are people making money selling them? The short answer is that the open source tools are kind of raw. They're dune buggies. Powerful, yes, and sufficient for a college project, but as it turns out, people buy Cadillacs, not dune buggies, to drive around in, because they like to have windshield wipers, 14-way power adjustable seats, and a way to start the engine from twenty feet away. Just in case you live in a Hollywood movie and the ignition has been hooked up to a bomb. Fog Creek (and others, notably GitHub) are making money selling version control by providing a whole bunch of features that make the overall code management experience easier and more useful. For example, we both provide professional, secure hosting, a web management and administration interface, and somebody you can call for help. Where we differ is that Kiln is more focused on the corporate market, while GitHub was designed for open source projects. I think of Kiln as the corporate Lincoln Town Car, while GitHub is kind of a VW Minibus. Both are eminently better choices than using raw Git. So, specifically, Kiln gives you corporate things like: code reviews access control and permissions fast code search a news feed to follow code you care about GitHub gives you things that match the sociology of open source projects: public home pages a social network, with profiles fork and pull workflow Since internal corporate projects have a very different sociology than open source projects, Kiln is very different than GitHub. On internal projects, almost all code that is developed is eventually used, although it needs to be reviewed, so Kiln kind of assumes that everything you do is most likely going to end up in the main code base, and we have a slick code review system. On open source projects, contributions can come from volunteers all over the Internet, many of whom are happy to fork the code for their own needs. So GitHub provides a social network, emphasizes the ease of forking someone else's code (something you're unlikely to do in a closed corporate environment), and has a thing called a pull request that matches the way people tend to collaborate on open source projects without advance coordination. ANYWAY, back to the new version of Kiln. When Tyler and Ben built Kiln 1.0, they built it on Mercurial. Why? Well, Mercurial had pretty much all the same concepts as Git, but Git was historically unfriendly to Windows which is used by many of our corporate clients. We also thought that the Mercurial command line (hg) was a bit closer to Subversion (svn) which a lot of programmers were already used to. So, long story short, we decided Mercurial was about 1% bett[...]