Ok, that covers hardware side. Now find someone competent to actually write some software to analyze, spec and run the stuff, QA it, cover the transition costs and factor in maintenance costs, staff and management overhead.
shouldn't have fired him, then. (oh, and multi-threading is one of most useful tools you can have in your arsenal. When applied properly it can solve rather large amount of problems or edge cases just by decoupling different parts of the system. Especially in the UI development.)
some of the greatest works of art in the history have been commisioned - for a price. Oh, wait, most of them. And if you have a blacksmith who cares not to be paid, you are looking at a blacksmith who will be on the street soon.
But that's the whole point. You cannot do things 'on the fly' if you don't understand why, how, and the risks associated. 'Duct-tape' guys are not just trowing stuff together. They are throwing stuff together that will get the job done without involving three weeks of design meetings, reviews and delegation to an off-shore team for implementation. They just Get The Job Done. And yes, it is an art. (nowhere in the article it was said that anyone can be one, au contraire, it was rather implied that only good ones can affort to try to be ones).
You missed the point. I do not advocate against process, I advocate against 'Process (signed off by board, three dev-leads and four external consultants)'. Anyone worth 2p will set up a process as soon as they touch anything. Even you have a process to take a piss - you unzip first, pull out second, do your stuff and then kinda clean up. In software development you often need to get 3 signatures and documented trail in your e-mail just to unzip:) And god forbid you even imagine thinking about letting it go without board approval!
You introduce junior ('cheap') people, and yes, you do screw up. There is nothing less insulting for a good developer than to see management covering up shit for a bad hire.
"I'm of the mind that with the right amount of management, organization, process, design, and documentation, actual "programming" is just glorified data entry." And perhaps you are wrong. Although if you do feel that programming can be reduced to glorified data entry, well, sometimes development is a bit more than just mucking around with the api calls in your preferred java IDE... Couple of points follows.
Good managers are much harder to come by than good developers. If you feel otherwise, I would be happy to see reasonable arguments - as far as I am concerned I have met/seen/worked with only three or, maybe, four competent technical managers versus at least ten to fifteen competent developers (sometimes you do not appreciate it until later, so, less precise here;)). Strangely enough there is some overlap between two sets. And here is the catch - bad developers are way easier to spot than bad managers - there actually is something measurable and no (often used) buffer to fall back to.
I do not dispute any of the things you listed, not by a long shot, just the form. In example - any company that focuses on documentation or formal QA - with all due respect, as far as I am concerned, is an excellent indicator of company that believes that there are tasks that can be delegated to 'junior' developers for cost reasons. Or the great big outsorcing to a team that might be part of the company or might not, but somehow are supposed to have an idea of everything that happens. Oh, and let us add a framework or two for that too. Similar to functional specifications, scheduled code reviews or design.
Software development is a game of context. Large context and it isn't going to become any smaller regardless of what you do. Unless you can reasonably well predict the effect of your innocent change in that pl/sql procedure feeding cgi handled C frontend pretending to be an RPC bound UI abstraction, all you are doing is taking stabs in the dark - no level of abstraction, interfaces or glue layers will help if the underlying assumption about using base 16 for all color values or cents stored as integers rounded to nearest 1/1000th turns out not to match whatever conversion/calculations/assumptions are done en-route. Scope-wise context while developing software is at least as large as actual business decisions, with the only difference being that when working with software most of the variables can at least be predicted. Financial impact by both can be pretty similar as some might have noticed. Oh, and you know what - good developers are perfectly capable to factor in business context in their work too. In fact, perhaps, it could be argued, that when developer/team actually is informed why any particular deadline has to be met or any particular feature is a must-have instead of being an ugly hack shoved in the last minute, better results follow. Perhaps worse code, since yes, for this deadline this particular hack could be allowed, but better results for sure.
I have nothing against anything you listed, all are absolute basics. And I couldn't imagine to work without proper, hot, intense and pouring jiras all over my inbox QA anymore, althou it should be noted that in my experience not always what managers think can be called a QA has anything to do with quality or assurance, quite often it is just an arbitrary signoff with no contribution whatsoever justifying some manager somwhere. Same for design documentation - a quick scratch on a napkin can, and often will be miles more valuable than your 500 page reiteration of buzzwords and copy-pasta of latest hot frameworks API - someone actually bothered to discuss what to do and how to proceed while only thing around was a napkin. Your plan with schedule and milestones is worthless - show me a single plan that actually matched reality, with the exception of those where you ended up with nice and comfortable 4-8 hour tasks and on every developers status meeting everyone was happily nodding that this is _exactly_ what they are working on 30.25% of
There is only one problem. UAVs on their own are pretty useless or we are talking about skynet teritory, but any kind of remote control is pretty easily distracted by good old white noise. Lots of it. And I am rather sure that good ol boys in their hidden cities have long ago figured out how to drown out all those fancy frequency-hopping/multi-modulation/line-of-sight radio signals that these things do rely on.
Forget all about agile, forget all about scrum and forget all about management. The only places where I have seen some good code actually being written are the places where there were no 'process', there were no 'evangelists' and it was absolutely normal for managers and devs to swap roles in who is managing who - naturally. No process will improve on a (welcomed) shout across the room and reply coming back in 5 seconds.
In production systems I do like to occasionally fight for a time off ('cleanup timeout or I quit!') and let someone else to have a stab at the code I feel I have fucked, really, really, fucked, up. And funny enough, when they do account for most/all the edge cases, two or three different input paths as per specifications and variations in states, it might not be the same, it might not be worse, but for sure as hell I am just about in a WTF mode reading their code as I can imagine anyone reading and deleting 'surplus' code blocks from mine are.
In real life code sucks. Just sucks, and it just doesn't involve you (again). Unless you manage to position yourself in nuclear plant or simlar critical systems where your inputs are guaranteed to be x to y and if not - oh well, it's too late anyway.
And as a word of warning - if you see a code that appears to be equal to 'if (1 == 1) return 1;)' - well, this is the time to become _extremely_ careful.
(*When I'm not drunk I dream of working in true RT-embeded systems with watchdogs, crystals, documentation describing cycles-per-instruction and no stupid heap sharing...)
No, the ads were served by a rogue ad network running via a botnet that incidentially relied on LSE as largest cluster it had managed to infect. Microsoft wasn't really advised by their marketing people whom exactly are they employing to run their campaigns.
Uhm? If you are allowing for possibility for the remote file to be "bigger", you are allowing for potential data corruption as well even if sizes match. What about three way protocol where there is also a script on the target machine that regulary generates md5 sums (and yes, we STILL can have collision there) for files present and.complete is uploaded only if the md5 matches.
Althou, obviously, this is braindead. I would probably go and just use something like rar with recovery records to make sure that I can detect any issues in one step. Or - just switch network provider, use VNP and then - all of the above together. Assuming that mission critical here indeed means "worth time to attempt to make sure that data gets there ASAP and verifyably* intact or else there will be millions lost."
Uhm? Yes, you can. Sure, you will need ether jailbroken phone or an iphone dev account (where they will happily give you all necessary keys to run anything you compile on your device), but still - ether is simple and easy to do.
Naah, piece of crap. Have to give them credit for prefetching results in js and feeding them rather quickly. (but apart from that - lousy, flashy (in a bad sense), and way off what I was looking for.
No, not really. Russians used to design things so that anyone could service them. That, and of course - from whatever materials were available. Oh, and of course - design to take into account that it will be put together by someone who really gives no crap whether design calls for 0.1mm precision or 1.5mm precision when assembling. As an anecdote - Russian tanks usually needed about a week of running-in followed by engine reassembly to clean out all the metal that has been shaved away from cylinders, heads and et-cetera.
Attitudes to (top) military and space stuff was a bit different though.
Second that. I haven't had XP crash on me in well over two years. I had some slowdowns and reinstalled about a year ago just to clean things up, but as far as BSOD or hang-ups goes - haven't seen it for quite a while. Only issue that bugs me is that XP fails to boot if I have external USB storage device plugged in - althou I suspect bios on that one.
Same for linux on the second machine. But then... on my (small and handy - perfect for flacs) spare athlon XP1800+/1G sdram I will have to install wXP to get any practical use of it - 8.04 and 9 betas ubuntu fails at playing back even basic DVDs (x11 must die and suspect savage4 drivers to suck). Might try windows 7 just for kicks on that one:D
So, in general - windowsXP is the new NT4sp6a for me. And by all looks might stay that way for a while.
Slashdot Mirror
Ok, that covers hardware side. Now find someone competent to actually write some software to analyze, spec and run the stuff, QA it, cover the transition costs and factor in maintenance costs, staff and management overhead.
shouldn't have fired him, then.
(oh, and multi-threading is one of most useful tools you can have in your arsenal. When applied properly it can solve rather large amount of problems or edge cases just by decoupling different parts of the system. Especially in the UI development.)
some of the greatest works of art in the history have been commisioned - for a price. Oh, wait, most of them. And if you have a blacksmith who cares not to be paid, you are looking at a blacksmith who will be on the street soon.
But that's the whole point. You cannot do things 'on the fly' if you don't understand why, how, and the risks associated. 'Duct-tape' guys are not just trowing stuff together. They are throwing stuff together that will get the job done without involving three weeks of design meetings, reviews and delegation to an off-shore team for implementation. They just Get The Job Done. And yes, it is an art.
(nowhere in the article it was said that anyone can be one, au contraire, it was rather implied that only good ones can affort to try to be ones).
You missed the point. I do not advocate against process, I advocate against 'Process (signed off by board, three dev-leads and four external consultants)'. Anyone worth 2p will set up a process as soon as they touch anything. Even you have a process to take a piss - you unzip first, pull out second, do your stuff and then kinda clean up. In software development you often need to get 3 signatures and documented trail in your e-mail just to unzip :) And god forbid you even imagine thinking about letting it go without board approval!
You introduce junior ('cheap') people, and yes, you do screw up. There is nothing less insulting for a good developer than to see management covering up shit for a bad hire.
"I'm of the mind that with the right amount of management, organization, process, design, and documentation, actual "programming" is just glorified data entry."
And perhaps you are wrong. Although if you do feel that programming can be reduced to glorified data entry, well, sometimes development is a bit more than just mucking around with the api calls in your preferred java IDE... Couple of points follows.
Good managers are much harder to come by than good developers. If you feel otherwise, I would be happy to see reasonable arguments - as far as I am concerned I have met/seen/worked with only three or, maybe, four competent technical managers versus at least ten to fifteen competent developers (sometimes you do not appreciate it until later, so, less precise here ;)). Strangely enough there is some overlap between two sets. And here is the catch - bad developers are way easier to spot than bad managers - there actually is something measurable and no (often used) buffer to fall back to.
I do not dispute any of the things you listed, not by a long shot, just the form. In example - any company that focuses on documentation or formal QA - with all due respect, as far as I am concerned, is an excellent indicator of company that believes that there are tasks that can be delegated to 'junior' developers for cost reasons. Or the great big outsorcing to a team that might be part of the company or might not, but somehow are supposed to have an idea of everything that happens. Oh, and let us add a framework or two for that too. Similar to functional specifications, scheduled code reviews or design.
Software development is a game of context. Large context and it isn't going to become any smaller regardless of what you do. Unless you can reasonably well predict the effect of your innocent change in that pl/sql procedure feeding cgi handled C frontend pretending to be an RPC bound UI abstraction, all you are doing is taking stabs in the dark - no level of abstraction, interfaces or glue layers will help if the underlying assumption about using base 16 for all color values or cents stored as integers rounded to nearest 1/1000th turns out not to match whatever conversion/calculations/assumptions are done en-route. Scope-wise context while developing software is at least as large as actual business decisions, with the only difference being that when working with software most of the variables can at least be predicted. Financial impact by both can be pretty similar as some might have noticed. Oh, and you know what - good developers are perfectly capable to factor in business context in their work too. In fact, perhaps, it could be argued, that when developer/team actually is informed why any particular deadline has to be met or any particular feature is a must-have instead of being an ugly hack shoved in the last minute, better results follow. Perhaps worse code, since yes, for this deadline this particular hack could be allowed, but better results for sure.
I have nothing against anything you listed, all are absolute basics. And I couldn't imagine to work without proper, hot, intense and pouring jiras all over my inbox QA anymore, althou it should be noted that in my experience not always what managers think can be called a QA has anything to do with quality or assurance, quite often it is just an arbitrary signoff with no contribution whatsoever justifying some manager somwhere. Same for design documentation - a quick scratch on a napkin can, and often will be miles more valuable than your 500 page reiteration of buzzwords and copy-pasta of latest hot frameworks API - someone actually bothered to discuss what to do and how to proceed while only thing around was a napkin. Your plan with schedule and milestones is worthless - show me a single plan that actually matched reality, with the exception of those where you ended up with nice and comfortable 4-8 hour tasks and on every developers status meeting everyone was happily nodding that this is _exactly_ what they are working on 30.25% of
And this is labeled funny? It sounds like it will easily hold up in court of peers :)
There is only one problem. UAVs on their own are pretty useless or we are talking about skynet teritory, but any kind of remote control is pretty easily distracted by good old white noise. Lots of it. And I am rather sure that good ol boys in their hidden cities have long ago figured out how to drown out all those fancy frequency-hopping/multi-modulation/line-of-sight radio signals that these things do rely on.
You, sir, are my hero. Don't be surprised to see this idea to be picked up by film industry soon! :)
Forget all about agile, forget all about scrum and forget all about management. The only places where I have seen some good code actually being written are the places where there were no 'process', there were no 'evangelists' and it was absolutely normal for managers and devs to swap roles in who is managing who - naturally.
No process will improve on a (welcomed) shout across the room and reply coming back in 5 seconds.
In production systems I do like to occasionally fight for a time off ('cleanup timeout or I quit!') and let someone else to have a stab at the code I feel I have fucked, really, really, fucked, up. And funny enough, when they do account for most/all the edge cases, two or three different input paths as per specifications and variations in states, it might not be the same, it might not be worse, but for sure as hell I am just about in a WTF mode reading their code as I can imagine anyone reading and deleting 'surplus' code blocks from mine are.
In real life code sucks. Just sucks, and it just doesn't involve you (again). Unless you manage to position yourself in nuclear plant or simlar critical systems where your inputs are guaranteed to be x to y and if not - oh well, it's too late anyway.
And as a word of warning - if you see a code that appears to be equal to 'if (1 == 1) return 1;)' - well, this is the time to become _extremely_ careful.
(*When I'm not drunk I dream of working in true RT-embeded systems with watchdogs, crystals, documentation describing cycles-per-instruction and no stupid heap sharing...)
Sounds fair enough - specifically implies that visitors are a fair game.
skin color?
uhm? Been producing britney spears lots?
sex.com
Should have used diff-hellman!
(noone ever talks about girl-in-the-middle attacks, right?)
Lotus Notes??? Really???
No, the ads were served by a rogue ad network running via a botnet that incidentially relied on LSE as largest cluster it had managed to infect. Microsoft wasn't really advised by their marketing people whom exactly are they employing to run their campaigns.
funny enough slashdot has been one of reference sites I test browsers with for quite a while. Incremental rendering in particular.
Uhm? If you are allowing for possibility for the remote file to be "bigger", you are allowing for potential data corruption as well even if sizes match. What about three way protocol where there is also a script on the target machine that regulary generates md5 sums (and yes, we STILL can have collision there) for files present and .complete is uploaded only if the md5 matches.
Althou, obviously, this is braindead. I would probably go and just use something like rar with recovery records to make sure that I can detect any issues in one step. Or - just switch network provider, use VNP and then - all of the above together. Assuming that mission critical here indeed means "worth time to attempt to make sure that data gets there ASAP and verifyably* intact or else there will be millions lost."
*Man in the middle?
Uhm? Yes, you can. Sure, you will need ether jailbroken phone or an iphone dev account (where they will happily give you all necessary keys to run anything you compile on your device), but still - ether is simple and easy to do.
Naah, piece of crap. Have to give them credit for prefetching results in js and feeding them rather quickly.
(but apart from that - lousy, flashy (in a bad sense), and way off what I was looking for.
No, not really. Russians used to design things so that anyone could service them. That, and of course - from whatever materials were available. Oh, and of course - design to take into account that it will be put together by someone who really gives no crap whether design calls for 0.1mm precision or 1.5mm precision when assembling. As an anecdote - Russian tanks usually needed about a week of running-in followed by engine reassembly to clean out all the metal that has been shaved away from cylinders, heads and et-cetera.
Attitudes to (top) military and space stuff was a bit different though.
Second that. I haven't had XP crash on me in well over two years. I had some slowdowns and reinstalled about a year ago just to clean things up, but as far as BSOD or hang-ups goes - haven't seen it for quite a while.
Only issue that bugs me is that XP fails to boot if I have external USB storage device plugged in - althou I suspect bios on that one.
Same for linux on the second machine. But then... on my (small and handy - perfect for flacs) spare athlon XP1800+/1G sdram I will have to install wXP to get any practical use of it - 8.04 and 9 betas ubuntu fails at playing back even basic DVDs (x11 must die and suspect savage4 drivers to suck). Might try windows 7 just for kicks on that one :D
So, in general - windowsXP is the new NT4sp6a for me. And by all looks might stay that way for a while.