This is horrible advice! Your method is why we have such shitty software and is why companies like Apple are stealing Microsoft's lunch! Yes the backend is important and you shouldn't neglect it, but the GUI is what drives the design of the backend! It is, in essence, the high-level requirements document for the entire application stack! If you don't have the GUI design, how the hell do you even know what the bowels of the application should be doing!?
It's the least important as far as overall functionality, but it's what everyone sees and reacts to.
The GUI is the most important because as you say, it the part that actually gets touched by non-programmers. The UI should drive the design of everything below it--including the database schema , the middleware, and things like the messaging protocols.
I don't like focusing on the GUI up front because their are usually many requirement changes and what not and would have to be redone anyway. Better to wait until a later stage when everyone has had a chance to think about what they really want.
You *should* do the GUI up front because the GUI dictates the design of the entire system. You don't have to make it hi-fidelity (i.e. functional)--you can get away with simple things like Paper Prototypes*. Let the design process be iterative and don't be afraid to throw bad ideas (literally). Paper is cheap, development time is not!
Alas, other departments, project managers, and what not only see the GUI and have no clue about what it takes to support the GUI underneath. The GUI is just the tip of the iceberg.
This is true, and is the exact reason you should nail down the GUI first. How they use it is all they care about, and is the exact reason why you should nail down those requirements before you do anything to your backend. They aren't gonna come bitching to you about how your databases lack some index, but they might complain that your list of videos isn't dropping stop words like "The" or "A". A change to how the list sorts could well affect the entire application stack. Do you want to know about that before or after you finished your backed?
If you do the backend before the front end, your backend will wind up driving the functionality of the GUI instead of your customer. In other words, if you do the GUI at the end, you've invested so much time into the backend it becomes very costly to make changes to the GUI that would necessitate fundamental changes to the backend.
Bottom line, your method is fundamentally wrong. Let the design of UI drive the backend, not the other way around.
* Some people do their mockups in visio or photoshop but I'm personally not a fan as it allows you to make an interface look too real and thus people focus on the colors and fonts when all you are after is the overall grid and the flow of different screens/pages. Worse, your customer might think you are closer to being finished then you actually are (after all, your prototype looked so good that we assumed it just needed the buttons wired in!) Worse still, doing it in visio or photoshop takes more time and the idea of initial prototypes is that you dont invest much time in them so you don't feel bad about throwing bad ideas away. Personally I dont even commit to ink when doing my initial designs, I do it in pencil and when I really like something I trace it over with a permanent marker.
The GNU folks, in general, abhor man pages, and create info documents instead. The maintainer of tar falls into this category. Thus this man page may not be complete, nor current, and was included in the Red Hat CVS tree because man is a great tool:). This man page was first taken from Debian Linux and has since been loving updated here.
man tar Yet another reason to switch from Linux. The crappy state of GNU documentation.
The 2.4 series was the last stable series of linux kernels in existence. 2.6 is in a perpetual state of bleeding edge, which makes it a gable to use on a system you care about. It is one of the reasons people (like myself) switched from 2.4 to one of the BSD's.
This is the part where I point out that c# can act as a low-levelish language. You can do pointer arithmatic and shoot yourself in the foot with buffer overruns just fine writing unsafe code.
Of course writing such low-level code in C usually looks more elegant than doing it in C#.
You think the only reason oil companies dont drill in shallower waters is NIMBY's worried about their view? You think the very same regulators that caused this mess by rubber stamping everything would give two shits about some assholes view?
Dude. If BP could be drilling in shallow waters, they'd be drilling in shallow waters NIMBY's be damned.
The elephant in the room here is they didn't. Why? Simple--we've tapped out all the oil in cheap & easy to reach locations.
And for the billions of customers without a high enough downstream to stream HD...
Yet. The codec that gets standardized on will be in use for decades to come. It will be embedded in the firmware of dvd players, cable tuners, mobile phones, car-stereos, you name it. You telling me that in a decade "billions of customers" will still be using crappy slow internet connections?
You are going to chose your codec based on "now" instead of thinking even five years into the future? How short sighted is that?
Once somebody discovers that little "720p" in the combo box, they pretty much always use it. 720p isn't really even enough pixels as my monitor is more than 1200px tall.
Right, and we should all revert back to sending text files via gopher or ftp... the presentation *is* part of the content. It sets the tone of whatever you happen to be reading or watching. Would you be likely to ride in an ambulance that had "Ambulance" on the side printed in comic-sans? Would you trust your retirement to an investment bank whose logo was printed in Times New Roman?
Part of what makes video content worthwhile is the quality of the video. Blocky video in 480x360 takes away from even the best subjects. Imagine watching avatar or star wars in 480x360...
The lone sentence paragraph is born out of the idea people generally skim while reading online. I do it all the time in emails because if I use any more than a few sentences people will not read what I wrote.
If anything, lone-sentence paragraphs are a by-product of information overload. We simply do not have the time nor the brain power to carefully read large amounts of text--especially when we are doing it for entertainment (i.e. posting on slashdot).
even though the rewrite will take less time than bolting hack after hack on top of the old system
Often the problem is we developers are wildly optimistic in our estimates of how long such a venture might actually take. Especially if we are talking about code we dont know much about. Until we really get to know the problem domain, it all sounds so easy:-)
In my opinion, what Joel really is against is a wholesale "drop everything you are working on and rewrite the entire app". From hard-won experience, he is right... When you drop everything you are working on, you stop pushing out exciting new features to your customers. Said customers get pissy that nothing seems to be changing and start to look elseware for their software fix.
Doesn't matter if the product is internal or something for the public. If it is internal, the teams who use your product start getting pissy with your team and look to out you. If it is external, your customers look to buying or using other competing products (like jumping from Netscape to IE5 and IE6).
If the old code really does suck (and if it is a combo of classic ASP and vbscript, it really does suck), the best route is to look at how to migrate your infrastructure a bit at a time to a better one.
For example, when you improve the admin site that uses ASP/vbscript, all new code has to use javascript and.net 4. Then hack the load balancer so that the requests get routed either to the legacy platform or the new platform.
Basically when you add a new feature or improve an existing one you port it to the new platform. That way you still maintain excitement by pushing out cool things while in the background you are improving your codebase. Yeah it might take a bit more time to crank out each new feature or fix, but at least you are cranking out bits and pieces instead of nothing for 5 years.
You put your virtualization on the new machines not on the hand-me-down stuff, silly. Your old machines weren't speced for them. You need to run the thing on a box that can take a crap-ton of RAM, has really fast I/O, and depending on the load, has the ability to take a NIC per VM.
"Virtualization is supposed to CUT costs, not incur new hardware costs"
It does cut costs... it cuts hardware costs by allowing you to buy fewer servers. Instead of buying new servers for DNS, LDAP, Web, and Email, you can buy one server, one license for the virtualization software, and consolidate the whole mess.
Cutting costs doesn't always imply using hand-me-down hardware. If the CPU doesn't have hardware VM built on it, it isn't an ideal candidate for serving virtual machines period. Those old servers might just have to sold on craigslist to some web-shop looking for extra web servers to shove behind their load balancer.
PS: This is one reason businesses lease servers instead of buy them. It makes it easy to cycle out the old junk every few years.
A tool that merges and optimizes all the CSS used in your site. A tool that magically figures out what CSS rules are not being used anywhere. A tool that suggests "hey, that selector is a bit more complex than needed for what you seem to be doing".
In otherwords, better tools to manage my stylesheets.
HTTP is actually not bad for simple forms of AJAX. AJAX is just a fancy method of one-way message passing (and basically a form of RPC).
Where HTTP breaks down is when you want to send events from the server to the client. Say you are facebook and want to update everybody when a friend logs in. To do this, the client either needs to listen on a port for messages from the server, keep a session open with the server at all times, or poll the server every so often for any new events. HTTP wasn't designed for keeping a session open*, polling the server isn't "instant", and the idea that the client should listen on a port is just a security nightmare.
I'd vote for holding a session open with the server. But there are problems--every major site is sitting on a cluster of servers. Every HTTP request is routed to a different server. You dont want to hold a session open on a single server as you'd overload it. Even if you tossed out HTTP and did some other protocol, you'd still have to deal with the load-balancing issue.
Maybe polling the server isn't so bad? Yeah it might generate more needless load on the backend, but it is also much simpler to implement than holding a session open the whole time.
I dunno.. I'm not a CS major. Probably somebody with a PhD in CS could invent a more elegant way of doing large-scale two-way message passing.
* Yeah, keep-alive, but keep-alive isn't meant for the same thing as what I'm talking about...
If you hotlinked the library from the official site, you'd basically be a leech and worse, your visitors would probably not get any of the benifits that come from loading jQuery from google (namely the fact the visitor probably has the google version in their cache already).
Off the top of my head, here are a few problems with the mryiad of many frameworks for the web: 1) The super-ultra-awesome slider you want is for YUI but the rest of your site uses jQuery. If you want to use it, you'll have to have the browser pull down both jQuery AND YUI. 2) Many of the frameworks conflict--prototype, for example, doesn't play nicely with a bunch of other frameworks. 3) Each framework added to your stack increases the number of moving parts on your site. More moving parts = more chance for error.
Seriously, it is a cruel joke when you find the-most-perfect-rich-text-editor but it was for MooTools instead of YUI.
*That* is my problem with having so many frameworks. The world would be a better place if we all just used jQuery:-)
And the reason they won't do better than the iPad is all of them will attempt to bolt on some desktop OS. Only devices that abandon desktop operating systems entirely (and magically attract the same amount of developers as Apple did) will compete.
This is a great way to have your co-workers think you're such a great guy as they walk all over you.
No, because you dish out the "you blew it" to the person in private or at most to the team. You never "punish" your team in front of external groups (i.e. your management, your clients, etc). The worst managers in the world are the ones who shame their group in public. The best managers are the ones who always present their team in the best light possible and keep the internal drama where it belongs--within the team.
Besides, it is true, as a manager if any person on your team blows it, ultimately it is you who failed. While it is true Joe the developer couldn't code his way out of a box, the external group doesn't know that.. they just see that your team failed to deliver a quality product and since the buck stopped with you, you are the one that failed. In private you give Joe the "you suck" speech, but in public, you say "My team gave it the best, but it was my fault".
Like the original poster said, this advice applies to pretty much everything but those holding elected office. Politics is not a group sport and it is every person for themselves. In politics, if you have to throw Joe under a bus to advance, so be it--they'd throw your ass under a bus as well. However, if you are an elected official and start throwing your appointees under the bus, it will come back to bite you as people will think you dont know how to pick good people. So maybe this advice applies even there as well.
But internally (i.e. to yourself), always set an expectation higher than what makes you comfortable. You should always, *always* under-promise and over-deliver externally (i.e. what you promise to deliver), but always make sure to sell yourself slightly outside of what you are comfortable with. Always push your comfort zone. If what you promise makes you a little nervous and afraid inside, it means you are forcing yourself to grow as a person. If what you promise makes you say "no problem", it means you are stuck in a rut.
I woudln't work at a place that used what I assume you meant was pirated software because places that pirate software are the kinds of places that will bounce your paycheck--not to mention as a software developer, your asset is the intellecutal property inside your brain and pirating software devalues the very thing you sell.
Aside from that, a professional *is* a highly trained prostitute. You offer your services, suggest your best ideas, but at the end of the day, you do what they want you to... because that is why you get paid.
Now if you actually meant "private software" as in "non RMS compliant software", then yes, you are a total religious zealot, nobody cares what you think (including me), and have zero relevance to 99.99999% of the world. Software isn't a religion. End of story.
It isn't they are set in their ways. It is that they've seen shit fail and know the warning signs. Your totally awesome idea about pair programming (hey, it says right in the XP book, they can't lie) might not be appropriate because XYZ. Your rad idea of cloud computing might be friggen awesome (everybody is doing it, you stone age losers) because I don't know, gee, you might have these pesky HIPAA regulations, whatever those are. Your idea of rewriting the codebase because the code is U.G.L.Y. might be totally awesome because you can totally do it in a week, but gee, the shit we have now works and it would take way longer than you estimate because, gee, that code has been around for *years*. Lord knows what kind of shit when into it to make it work--that code has history man.
Bottom line is, the most important thing is to admit you do not know jack shit. Better to admit you don't know anything because, brother, we all don't know shit--even people who have been there, done that. The people that truly do not know anything tend to be the ones that always brag about knowing everything. I have yet to meet a person who brags about knowing stuff that actually knows stuff.
Slashdot Mirror
This is horrible advice! Your method is why we have such shitty software and is why companies like Apple are stealing Microsoft's lunch! Yes the backend is important and you shouldn't neglect it, but the GUI is what drives the design of the backend! It is, in essence, the high-level requirements document for the entire application stack! If you don't have the GUI design, how the hell do you even know what the bowels of the application should be doing!?
The GUI is the most important because as you say, it the part that actually gets touched by non-programmers. The UI should drive the design of everything below it--including the database schema , the middleware, and things like the messaging protocols.
You *should* do the GUI up front because the GUI dictates the design of the entire system. You don't have to make it hi-fidelity (i.e. functional)--you can get away with simple things like Paper Prototypes*. Let the design process be iterative and don't be afraid to throw bad ideas (literally). Paper is cheap, development time is not!
This is true, and is the exact reason you should nail down the GUI first. How they use it is all they care about, and is the exact reason why you should nail down those requirements before you do anything to your backend. They aren't gonna come bitching to you about how your databases lack some index, but they might complain that your list of videos isn't dropping stop words like "The" or "A". A change to how the list sorts could well affect the entire application stack. Do you want to know about that before or after you finished your backed?
If you do the backend before the front end, your backend will wind up driving the functionality of the GUI instead of your customer. In other words, if you do the GUI at the end, you've invested so much time into the backend it becomes very costly to make changes to the GUI that would necessitate fundamental changes to the backend.
Bottom line, your method is fundamentally wrong. Let the design of UI drive the backend, not the other way around.
* Some people do their mockups in visio or photoshop but I'm personally not a fan as it allows you to make an interface look too real and thus people focus on the colors and fonts when all you are after is the overall grid and the flow of different screens/pages. Worse, your customer might think you are closer to being finished then you actually are (after all, your prototype looked so good that we assumed it just needed the buttons wired in!) Worse still, doing it in visio or photoshop takes more time and the idea of initial prototypes is that you dont invest much time in them so you don't feel bad about throwing bad ideas away. Personally I dont even commit to ink when doing my initial designs, I do it in pencil and when I really like something I trace it over with a permanent marker.
man tar
Yet another reason to switch from Linux. The crappy state of GNU documentation.
The 2.4 series was the last stable series of linux kernels in existence. 2.6 is in a perpetual state of bleeding edge, which makes it a gable to use on a system you care about. It is one of the reasons people (like myself) switched from 2.4 to one of the BSD's.
This is the part where I point out that c# can act as a low-levelish language. You can do pointer arithmatic and shoot yourself in the foot with buffer overruns just fine writing unsafe code.
Of course writing such low-level code in C usually looks more elegant than doing it in C#.
You think the only reason oil companies dont drill in shallower waters is NIMBY's worried about their view? You think the very same regulators that caused this mess by rubber stamping everything would give two shits about some assholes view?
Dude. If BP could be drilling in shallow waters, they'd be drilling in shallow waters NIMBY's be damned.
The elephant in the room here is they didn't. Why? Simple--we've tapped out all the oil in cheap & easy to reach locations.
Do what the big-boys do and require the script to be code signed to run in a background tab?
I dunno... might be an overkill to what amounts to a theoretical attack vector though.
Yet. The codec that gets standardized on will be in use for decades to come. It will be embedded in the firmware of dvd players, cable tuners, mobile phones, car-stereos, you name it. You telling me that in a decade "billions of customers" will still be using crappy slow internet connections?
You are going to chose your codec based on "now" instead of thinking even five years into the future? How short sighted is that?
Once somebody discovers that little "720p" in the combo box, they pretty much always use it. 720p isn't really even enough pixels as my monitor is more than 1200px tall.
Right, and we should all revert back to sending text files via gopher or ftp... the presentation *is* part of the content. It sets the tone of whatever you happen to be reading or watching. Would you be likely to ride in an ambulance that had "Ambulance" on the side printed in comic-sans? Would you trust your retirement to an investment bank whose logo was printed in Times New Roman?
Part of what makes video content worthwhile is the quality of the video. Blocky video in 480x360 takes away from even the best subjects. Imagine watching avatar or star wars in 480x360...
The lone sentence paragraph is born out of the idea people generally skim while reading online. I do it all the time in emails because if I use any more than a few sentences people will not read what I wrote.
If anything, lone-sentence paragraphs are a by-product of information overload. We simply do not have the time nor the brain power to carefully read large amounts of text--especially when we are doing it for entertainment (i.e. posting on slashdot).
People have been bitching about the downfall of their language since humans invented it.
It wasn't but a few centuries ago that we didn't even have consistent punctuation nor did we have any real notion of paragraphs.
Often the problem is we developers are wildly optimistic in our estimates of how long such a venture might actually take. Especially if we are talking about code we dont know much about. Until we really get to know the problem domain, it all sounds so easy :-)
In my opinion, what Joel really is against is a wholesale "drop everything you are working on and rewrite the entire app". From hard-won experience, he is right... When you drop everything you are working on, you stop pushing out exciting new features to your customers. Said customers get pissy that nothing seems to be changing and start to look elseware for their software fix.
Doesn't matter if the product is internal or something for the public. If it is internal, the teams who use your product start getting pissy with your team and look to out you. If it is external, your customers look to buying or using other competing products (like jumping from Netscape to IE5 and IE6).
If the old code really does suck (and if it is a combo of classic ASP and vbscript, it really does suck), the best route is to look at how to migrate your infrastructure a bit at a time to a better one.
For example, when you improve the admin site that uses ASP/vbscript, all new code has to use javascript and .net 4. Then hack the load balancer so that the requests get routed either to the legacy platform or the new platform.
Basically when you add a new feature or improve an existing one you port it to the new platform. That way you still maintain excitement by pushing out cool things while in the background you are improving your codebase. Yeah it might take a bit more time to crank out each new feature or fix, but at least you are cranking out bits and pieces instead of nothing for 5 years.
Course, this is my opinion. Yours may very.
You put your virtualization on the new machines not on the hand-me-down stuff, silly. Your old machines weren't speced for them. You need to run the thing on a box that can take a crap-ton of RAM, has really fast I/O, and depending on the load, has the ability to take a NIC per VM.
"Virtualization is supposed to CUT costs, not incur new hardware costs"
It does cut costs... it cuts hardware costs by allowing you to buy fewer servers. Instead of buying new servers for DNS, LDAP, Web, and Email, you can buy one server, one license for the virtualization software, and consolidate the whole mess.
Cutting costs doesn't always imply using hand-me-down hardware. If the CPU doesn't have hardware VM built on it, it isn't an ideal candidate for serving virtual machines period. Those old servers might just have to sold on craigslist to some web-shop looking for extra web servers to shove behind their load balancer.
PS: This is one reason businesses lease servers instead of buy them. It makes it easy to cycle out the old junk every few years.
Awesome!
For those who dont know, there is a Firebug addin called "CSS Usage". Get it here: https://addons.mozilla.org/en-US/firefox/addon/10704/
A tool that merges and optimizes all the CSS used in your site. A tool that magically figures out what CSS rules are not being used anywhere. A tool that suggests "hey, that selector is a bit more complex than needed for what you seem to be doing".
In otherwords, better tools to manage my stylesheets.
Just thinking here...
HTTP is actually not bad for simple forms of AJAX. AJAX is just a fancy method of one-way message passing (and basically a form of RPC).
Where HTTP breaks down is when you want to send events from the server to the client. Say you are facebook and want to update everybody when a friend logs in. To do this, the client either needs to listen on a port for messages from the server, keep a session open with the server at all times, or poll the server every so often for any new events. HTTP wasn't designed for keeping a session open*, polling the server isn't "instant", and the idea that the client should listen on a port is just a security nightmare.
I'd vote for holding a session open with the server. But there are problems--every major site is sitting on a cluster of servers. Every HTTP request is routed to a different server. You dont want to hold a session open on a single server as you'd overload it. Even if you tossed out HTTP and did some other protocol, you'd still have to deal with the load-balancing issue.
Maybe polling the server isn't so bad? Yeah it might generate more needless load on the backend, but it is also much simpler to implement than holding a session open the whole time.
I dunno.. I'm not a CS major. Probably somebody with a PhD in CS could invent a more elegant way of doing large-scale two-way message passing.
* Yeah, keep-alive, but keep-alive isn't meant for the same thing as what I'm talking about...
The official site recommends you load it from google. Why? Cause the fine folks at jQuery make a kick-ass javascript library, not a global content distribution network.
If you hotlinked the library from the official site, you'd basically be a leech and worse, your visitors would probably not get any of the benifits that come from loading jQuery from google (namely the fact the visitor probably has the google version in their cache already).
Off the top of my head, here are a few problems with the mryiad of many frameworks for the web:
1) The super-ultra-awesome slider you want is for YUI but the rest of your site uses jQuery. If you want to use it, you'll have to have the browser pull down both jQuery AND YUI.
2) Many of the frameworks conflict--prototype, for example, doesn't play nicely with a bunch of other frameworks.
3) Each framework added to your stack increases the number of moving parts on your site. More moving parts = more chance for error.
Seriously, it is a cruel joke when you find the-most-perfect-rich-text-editor but it was for MooTools instead of YUI.
*That* is my problem with having so many frameworks. The world would be a better place if we all just used jQuery :-)
awesome. I'll friend you just for spite.
And the reason they won't do better than the iPad is all of them will attempt to bolt on some desktop OS. Only devices that abandon desktop operating systems entirely (and magically attract the same amount of developers as Apple did) will compete.
No, because you dish out the "you blew it" to the person in private or at most to the team. You never "punish" your team in front of external groups (i.e. your management, your clients, etc). The worst managers in the world are the ones who shame their group in public. The best managers are the ones who always present their team in the best light possible and keep the internal drama where it belongs--within the team.
Besides, it is true, as a manager if any person on your team blows it, ultimately it is you who failed. While it is true Joe the developer couldn't code his way out of a box, the external group doesn't know that.. they just see that your team failed to deliver a quality product and since the buck stopped with you, you are the one that failed. In private you give Joe the "you suck" speech, but in public, you say "My team gave it the best, but it was my fault".
Like the original poster said, this advice applies to pretty much everything but those holding elected office. Politics is not a group sport and it is every person for themselves. In politics, if you have to throw Joe under a bus to advance, so be it--they'd throw your ass under a bus as well. However, if you are an elected official and start throwing your appointees under the bus, it will come back to bite you as people will think you dont know how to pick good people. So maybe this advice applies even there as well.
But internally (i.e. to yourself), always set an expectation higher than what makes you comfortable. You should always, *always* under-promise and over-deliver externally (i.e. what you promise to deliver), but always make sure to sell yourself slightly outside of what you are comfortable with. Always push your comfort zone. If what you promise makes you a little nervous and afraid inside, it means you are forcing yourself to grow as a person. If what you promise makes you say "no problem", it means you are stuck in a rut.
then you are forgiven my good sir. Please go about your daily routine knowing you have been blessed :-)
I woudln't work at a place that used what I assume you meant was pirated software because places that pirate software are the kinds of places that will bounce your paycheck--not to mention as a software developer, your asset is the intellecutal property inside your brain and pirating software devalues the very thing you sell.
Aside from that, a professional *is* a highly trained prostitute. You offer your services, suggest your best ideas, but at the end of the day, you do what they want you to... because that is why you get paid.
Now if you actually meant "private software" as in "non RMS compliant software", then yes, you are a total religious zealot, nobody cares what you think (including me), and have zero relevance to 99.99999% of the world. Software isn't a religion. End of story.
It isn't they are set in their ways. It is that they've seen shit fail and know the warning signs. Your totally awesome idea about pair programming (hey, it says right in the XP book, they can't lie) might not be appropriate because XYZ. Your rad idea of cloud computing might be friggen awesome (everybody is doing it, you stone age losers) because I don't know, gee, you might have these pesky HIPAA regulations, whatever those are. Your idea of rewriting the codebase because the code is U.G.L.Y. might be totally awesome because you can totally do it in a week, but gee, the shit we have now works and it would take way longer than you estimate because, gee, that code has been around for *years*. Lord knows what kind of shit when into it to make it work--that code has history man.
Bottom line is, the most important thing is to admit you do not know jack shit. Better to admit you don't know anything because, brother, we all don't know shit--even people who have been there, done that. The people that truly do not know anything tend to be the ones that always brag about knowing everything. I have yet to meet a person who brags about knowing stuff that actually knows stuff.