Code needs continuous improvement. Technology wants continuous improvement. Process wants continuous improvement. Agile / lean are the latest improvement. Concepts and patterns want names - buzzwords if you will - so we can agree what we are talking about.
Agile and lean were wildly successful methodologies long before they anointed with a buzzword. Is it crap? Evidenced by the rampant success of Toyota (lean) vs GM (conventional methodology), it is not crap. Agile and lean are not "new" at this point - they are now the minimum bar in most industries. Processes even better than the agile / lean methodologies sure exist. Those companies will thrive and a new buzzword will come into play.
Fortunately for you, you don't have to be interested in process improvement to be a programmer (only code improvement). You do have to be interested to be a successful manager or lead, though.
The article was beautifully insightful - where the rags are just inciting. It actually addresses many of the rags against agile.
Agile thrives when people get past the initial learning curve (past the checklist, as Cockburn points out in the article), re-read the agile manifesto, and intelligently apply the principals.
Cleanroom sounds interesting. Perhaps I hyperbolized if I indicated that TDD is the ONLY method of creating reliable software. It is, however, one of the cheapest and easiest.
"Which is cute, except that a lot of real world software development doesn't fall into neat little boxes like that.."
Not just cute, but very valid. Most real world, usable software can be broken down into neat little boxes, and should, for more reasons that just TDD support. Budgets change, financial systems crash and leave you without credit lines... Breaking down features into small chunks is necessary to ensure that you produced some value before your product was unexpectedly canceled. That's a principle well beyond TDD. My company has several massive projects going forward rapidly, on budget, broken down into small pieces, just like this. We are less worried then others about change, precisely because, while we have much more to do and many months to do it in, we have we could sell right now. A lot of people believe you can't break this stuff down, don't... and go out of business when vaporware v2 isn't done on time. We'd just ship 90% of the features as V2.
Also remember TDD is mainly about about unit tests. Your combination argument applies to integration tests, and is the main reason to apply strict TDD (with unit tests). Some math...
I create components with clearly defined responsibility and few dependencies. It might have 3-4 methods and perhaps 10-100 test cases. In unit tests, this is possible. It's easy enough that you can easily dig into the edge cases for each component.
If we start at integration testing or manual testing, combining 4 or 5 of these components, we have an unmanageable test matrix. You'll never cover the base cases, much less the edge cases.
e.g Just last week, I headed off a subtle bug starting from an incorrect comparison leading to bad sort and on to total badness. After applying a refactoring recipe straight out of most TDD books, I discovered I could get to the edge cases of a sorter very rapidly. The integration test would have required an large and complex test data set. The bug would be lost in the details.
The TDD hypothesis is that you achieve reliability faster by ensuring that each component is extremely reliable, and combining reliable components. Interesting integration cases are the domain of the quality assurance professional. If the components are reliable, QA will have time for interesting testing. If not, they will fill there days filing mindless functional bugs and miss massive problems.
"One of the problems I have with these "experts"... I won't get into an argument about authority. My point is, most any book or resource about TDD, unit testing, or the like, does not omit the role of manual testing. The back cover of the book might omit it. Most agile methodologies will also combine TDD with continuous integration and rapid, manual, QA cycles. Same idea: get results as fast as possible, fix as fast as possible, know that when you are done, you are really done.
My experience strongly confirms the TDD hypothesis. However, there are dozens of ways to achieve quality. Regarding this book and review: TDD works for many people, for those who buy the TDD hypothesis, Feathers' book is great.
Your argument seems plausible, until you have actually seen the difference in products developed with test-driven / unit test first approaches. The benefits are not what you think they are. I would agree that unit tests are not a panacea, but disagree on
1) The are essential, not just helpful, at least, if you intend to produce software that works. 2) Unit tests do not need to be comprehensive to be useful. They don't need to be great, but great helps.
I tend to agree with you on 1) unit tests are not integration tests, and also do not replace smart human testers. 2) No TDD or agile expert would include the word "anything" in this statement "When good unit tests are in place, then code can be changed at will and the tests will tell automatically you if you broke anything"
Here is what does happen in initial development with TDD / Agile. First, you write tests first, based on clear user stories. Then you write code to pass to pass tests (one at a time). This saves massive amounts of time: you avoid unnecessary code, over-design, and unnecessary features.
You see a side benefit quickly: In order to get code into true unit tests, each module has to do something meaningful on its own. You avoid the massive stink of excessive interdependency that paralyzes much OO code. (Much of Feather's book is about how to break those dependencies in order to test code).
Now, 1 or 2 weeks later (agile development gives you something interesting to look at in a week or two, not a month or two), it's either time to clean up the code, or you found you really misunderstood the problem. With this test coverage, it is enormously easily to re-factor.
But a warning: If you were writing integration tests (not unit tests), you'll find the tests are in the way. You make 1 change, and 10 tests fail. Done correctly, 1 change, 1 unit test fails. xUnit Test Patterns might be a good book, if you have this problem.
Is the coverage helpful or essential? Most of the code I work on has complexity rated at mind-boggling. Not only is it helpful to have the coverage, it's essential. I don't want to attempt to remember all 200 rules and exceptions when each behavior is complex enough. And don't want to wait 2 weeks for QA to finish their test pass. Good coverage means I make a change, and know immediately. I can let QA know risks that can't be covered in unit tests, and they can do some valuable work in discovery. Essential!
This book has been essential to me over the last 2 years: I've been keeping the "legacy" parts of a large web application running while others went on to develop cool new features. Let's just say this, there are two different challenges in software:
Challenge 1) Create a good design from scratch. Lots of folks can do this.
Challenge 2) Move from bad design or bad code to good design, while keeping the product running. Transforming a design in small re-factoring steps is vastly harder than rebuilding, but usually necessary.
This book is about that second, harder challenge. It emphasizes testing and testability, because that is how you ensure the product continues to run while you make the necessary changes. It does tend to assume you know what the good design you aim for is.
This is a very important book to have on your bookshelf, and will probably not become obsolete soon.
I doubt that long term studies have been completed. It doesn't seem like ZIFs are extremely new, this process for creating them and this particular variation are new. That said, several other sources provide better information than the CBC link and speak directly to your question. The CBC article states in first paragraph: "the crystals are non-toxic and would require little extra energy from a power plant."
Currently, the process of capturing carbon dioxide emissions from power plants involves the use of toxic materials and requires 20 to 30 percent of the plant's energy output, Yaghi said. By contrast, ZIFs can pluck carbon dioxide from other gases that are emitted and can store five times more carbon dioxide than the porous carbon materials that represent the current state-of-art.
Yaghi's initial idea of what to do with the material afterwards appears to involve geologic storage.
It's also always useful to hunt down the primary source. I think this PDF is it (I only skimmed).
Of course, it's always entertaining to imagine how much better I could run the country.
If you were going to pick an SLDC as a hypothetical model, I would prefer models based on Agile Principles, perhaps with some scrum. These would also address the concern of time. Some of the characteristics of such a system might be:
The congress (as product owners) defines the intent (e.g. User Stories) and acceptance cases in brief non-technical terms. Perhaps the full congress must ratifies this brief statement of intent before some comittee continues to work out the details.
QA moves upstream: There is immediate (judicial) review that validate that legislation meets its intent, does not violate the constitution and so forth. I don't ship incomplete features, congress doesn't ship bad legislation. No easter eggs in software or legislation. Some control that ear-marks are in line with the intent of an appropriations bill, and so forth.:)
Remember who the "customer" of legislation is - "for the people". I preview my software very early on to ensure it works. Perhaps face to face demonstration and explanation of legislation to stake holders becomes required. For example, city lawmakers wishing to criminalize sleeping in public places would have discuss with stakeholders (the homeless) how to make this legislation workable. We can have fun with this one:)
Congress might also set some high level acceptance cases for all legislation, which must be met. Beyond constitutionality, they might demand that all legislation is budge neutral.
Anyone can submit to the backlog. An initiative process would differ and be lighter weight: Initiatives might mandate the acceptance cases, binding professional lawmakers to create legislation within those parameters.
Prototype and pilot legislation. Perhaps congress could find volunteers among states to assist in this. Texas might like no child left behind, but Oregon thinks it has serious unresolved problems.
Ranked priority for legislation. Congress prioritizes their issues and must pass the laws in order of priority. No holding that hard budget bill to the last minute.
Direct quote from agile manifesto:
Simplicity--the art of maximizing the amount
of work not done--is essential.
Many posts are correct that the challenge is sale and buy-in. I'll just chime in to agree that media wikis are transformative. Valuable documentation is documentation that is easy to find and kept up to date.
I've seen the following set up with little success at previous companies
Binder - never found, never updated
Sharepoint - Purchase Order complete next year (always next year). Hard to use.
Custom HTML intra nets - Clunky to update, inconsistent. Usually involve clumsy change control processes.
Specialized document management software - you can never afford enough licenses for these to be effective
Media wiki: Easy and cheap to set up. Easy to find stuff. Anyone can update to correct inaccuracies (or roll back incorrect edits). We combine it with a local Google search Appliance and I can find anything I need in seconds. I can't imagine documenting process, or anything else, in any other way.
The approach discussed works on "... a simple premise: driving somewhere usually requires crossing major intersections that are sparsely interconnected. "
Ask yourself frankly, was I just slacking, or did I not get it?
If you were just slacking the first time around, most of the posts in this forum are applicable. Take classes, get texts, etc. Just set reachable goals and keeping whacking away at them. Classes will keep you on track.
If you genuinely had trouble with it, the first or second book in your scheduled reading might actually be in cognitive science, pedagogy and so forth. Various fads have swept the nation in math education. Ignore the fads and you'll find most of the basics are the same. Anyway, young kids have a learning advantage in many ways, but adults can understand how to learn something, which can make all the difference. Just for example, part of maturation is better skills at handling frustration. When you hit sticking points, you will have the ability to say: why am I confused? What part of this problem is hard and what part is easy? OK... what do I do about this?
I love my 20 minute afternoon power nap. If you are face down on the keyboard it looks like falling asleep on the job. I stretch out on the floor with a pillow to make it clear I'm recuperating, not lazy! In all other matters, I attempt to maintain a more "proper" demeanor.
Driving efficiently needs to be made as cool as driving aggressively. There are "hypermiling" competitions out there for who can get the best gas mileage through an in-city route.
I've tried driving for excessive fuel economy and found it a fun challenge. If you need to feel "cool", cornering at high speeds to avoid braking. There's the challenge of knowing exactly when to start coasting to pull to a stop at home without braking or accelerating. I'm getting c 32 MPG in-city these days on a car rated at 24MPG in city. Hope to break 40 MPG at some point.
My personal preferences align with your statements, but I doubt it will make any difference in the battle of Google vs MS. Money will matter. I also think that the Slashdot has picked up a red herring in the author's statements about Click - Once and the VM.
While interoperability is a much stronger technical argument than Security and some of the other cases made in this discussion, is it a business argument?.NET applications can't run on 5% of desktops. Will that 5% affect the MS bottom line? Not much.
OK, we can point out that we see almost no end-user oriented web sites using web-deployed Rich UI, or click once technologies. That 5% of machines can't run.NET rich apps becomes a barrier if you a bank providing access to customers. (It's a small annoyance if you are a corporate IT shop. )
Does this mean that.NET the business model is flawed? No. It's obvious that MS is very aware of that the problem that public web sites won't start using.NET rich UI's extensively. Consequently, MS pushes their web (ASP) framework much harder than their rich UI tools. Frankly, it's almost as if Winforms is an afterthought in visual studio. MS can make plenty of money off IIS / ASP / Sharepoint and other server technologies that provide access to clients running any platform with a reasonably modern browser and the ability to run javascript.
Where's the interoperability problem in MS development software? More specifically, is there an interoperability problem that will affect their revenue at all? No, there isn't.
Like most of the Slashdot readership, I'd personally prefer that the technology that "wins" is the best technical solution, that it will run on any machine in any form, etc. However, the beauty of a technology doesn't make a business case. A vast number of technology companies died in the late 90's partly because they failed realize that end users' cash pays for their products, not the admiration of other nerds.
I won't go on to discuss how this applies to the Google v MS fight. The article author failed to explain how a company that makes most of it's money off advertising competes with a company that makes most of it's money off software license fees, so I'm not sure where to start.
Can't agree more that external hard drives are the way to go for home users. I'd suggest two for anyone with data of any value.
CD/DVDs: - Not big enough. I end up with too many disks. - Too slow - I never get around to backing stuff up. - Probably won't be readable in 10 years (disk will degrade, if readers are available). - They are still great for sending Grandma pictures of her Great-Grandkids.
Prefered: 0. Data must be on 1-2 disks, no more. 1. 2 big external drives. 2. Second drive is always two years newer. 3. Keep copying data forward to new drives. 4. Do you really need backup software?
Data on just one- two disks: Any backup that requires switching disks won't get done. Besides, I wouldn't be able to find my stuff in 100 disks from the last 10 years.
Keep 2 Devices: I tend to carry my external drive around. While this means its safe from fire at home, it also gets abused. So, I need two backup drives. If you're really paranoid, keep one in a safe deposit box.
Second drive is newer / copy data forward onto new drives: This is the key to the longevity. I demand that my data storage system ensure that children have access to their baby pictures 20 years from now. The data won't be available if it's on any medium which will be obsolete in the future. This is any medium (hard drive, cd, etc) currently in use, except paper and stone tablets. To solve this, I plan on buying a new disk every 2 years, and copying data forward onto newer drives. To be practical, this should be one copy operation... not shifting out 200 obsolete CD's onto 50 DVD's every couple of years.
The copy-forward solution also prevents inevitable degradation of the disk. CD's will probably have died in 10-20 years - or gotten lost. I've got some compositions from the 1990s on floppy disks that are (fortunately?) lost to the world.
Do you need backup software? I suppose backup software is useful, but I can currently execute xcopy "[location of my stuff]" "[external drive]"/e/d in 1-10 minutes over USB 2.0. (Linux geeks may point out the vastly superior Unix options). I'd like something with a little better differencing, but xcopy works for me.
Do you sometimes wonder why MS has purchased and is investing in virtualization technology? A compelling strategic / tactical reason would be to leverage it to break out of the backwards compatibility problem.
They certainly aren't doing this so that you can run Linux on Windows. That would reduce switching costs and be bad strategy. Buying virtualization could be just another niche market or attempt to fill the product space - but that's not hugely compelling. It doesn't look like they bought the product to kill it. If that were the case, they'd also need to buy VMWare.
Here's one scenario: Once their virtualization technology is stable (almost there?), they integrate it into their OS. Windows NT 7 (is Windows Vista NT 6 or NT 5.x?) could totally break backwards compatibility, and run old apps in a virtualization layer running the old OS. Maybe NT 7 will include machines and API's optimized and tested to run each specific previous release of Windows.
Pushing the.NET framework gives them the abstraction layer they need to make this work with existing code and without virtualization. You can run.NET code in Mono on Linux... it should be trivial to make it work in a different Windows OS. Currently, there are only small sets of features you lose when running.NET on old windows versions... and the framework usually handles these very gracefully. No XP styles? Use a default color... etc.
Indigo style communications layers could theoretically even make communication between a virtuallized Win2K and the theoretical host OS possible, particularly if the virtualization technology is embedded and integrated in the OS. OK, it'd be slow... but since when did MS care about that? They have more bundling and anti-trust problems to deal with by integrating another product into the OS... but MS seems to prefer throwing lawyers at this type of problem.
An excellent list that engineers would understand. To this I'd add:
System / Integration testing: Periodically run your document by one of the people in its audience. Make sure that your point comes across accurately, and that they can easily find the information that they want. This is a very fast way to learn what works and what doesn't work in communication techniques.
Work with users to determine feature prioritization: Create an outline for project documentation, and ask project team - which headings will you actually use? Delete the other headings and save yourself time. This makes for a more concise document, which is more likely to be read.
While stating "deliberately held back a security patch" might be factually correct and a good catch line, I think it's highly misleading: it directs the reader towards many of the wrong conclusions.
Later in the article: "Officials -- not unreasonably, say security experts -- wanted to test the patch before installing it." Well, duh. This is the interesting story. They couldn't get through the tests that they SHOULD do fast enough.
The problem is agility and testability of the systems and deployment. The easiest solution has nothing to do with MS, nothing to do with windows, and everything to do with giving your test group more respect and resources.
This is not a problem inherently Microsoft's making. You can argue up and down that patches should be faster, product more secure etc. In the end, it's plausible that discovery, patch, exploit can come with bad timing in any system. System admins and project managers that don't plan for this are asking for trouble.
Elaboration: I push very hard to ensure that all my products have automated tests. My company's Desktop Engineering department requires automated tests of all its myriad apps (DE is not my department, won't take credit). I force redesign if a product can't be tested cheaply. The benefit is: I need new feature x tomorrow (maybe some suprise regulation) or company needs patch y tomorrow (e.g. Zotob worm). Where we've achieved our test automation goals (haven't in all cases, but our coverage is good enough), we can hit a few buttons, run our tests. Repeat on all 20 configurations / platforms. 90% of the time, we find no problems, and can deploy. If it's critical, you take the risk and deploy. If not, you go on to slower manual testing to complete coverage.
Had this US-VISIT program implemented adequate and automated tests, they could have deployed in a few days, not a few weeks. The methods and tools to do so have nothing to do with Microsoft. They don't even make the type of test automation tool required for this - although I know they have one for internal use.
As part of their release, they have a contest with some useless prizes. The interesting bit is that they are encouraging me to use open source licensing (see "Rules" section):
In addition to submitting your Mash-Ups via the submissions process described above, you must host the source code for each of your submitted Mash-Ups.... You may make the source code for your Mash-Ups available under the license of your choice. However, we encourage you to make the source code available under a BSD-style license, such as the Academic Free License, the Apache License 2.0, the New BSD license, or the MIT license...
The information you requested is in the third paragraph of the article, albiet not in depth. It describes types of jobs expected to grow in the U.S.
"...the U.S. IT sector's overall growth should outpace that loss of jobs, expanding opportunities for those trained in fields such as software architecture, product design, project management and IT consulting..."
Later, the article names some specific industries:
"... there will be continued growing demand for IT as underserved fields such as health care, retail trade, construction, and certain services make greater investment in technology."
I swear this could be someone in my team. Hell, it could be me. Your screen name is my real name. Frightening. This is the same world I live in.
Some problem definitions: Problem 1: Territory Central IT has a valid objective of maintaining standards for the purpose of security, etc. They do not have a valid mandate to do all the work themselves, if they can't do it to your timeline.
Problem 2: Power and influence Outside IT, it may appear that you don't have the necessary influence to force change on IT. e.g. I could save my company bundles by putting in a real middleware solution, but don't have to influence to push it.
Problem 3: Non-lean processes Many beaurocratic processes don't add value. This is where we get frustrated. You needed your RAM now, but it got delivered 9 months from now. My IT department saved me 5% on the cost of dev tools -- after 10-20 staff hours of meetings (at >$50 per person per hour = $500-$1000) that wiped out all benefits.
Approach to problem 1: Recognize that the IT department has a valid mandate to enforce security and other guidelines. Include them as stakeholders in planning, but reach a compromise where you can implement yourself. IT validates that product X is a good thing and adds their requirements. I'll go buy it and install it on my own, thanks. This can save months waiting for some bean pusher to remember to send a purchase order out.
Practice this yourself: never insist on doing something yourself, if someone else is perfectly capable.
Approach to problem 2: Get sponsorship at the highest level you can. You'll be suprised at the results you can get. IT is a cost center. If you don't report to IT, you probably represent a department that earns the company money. Getting sponsorship at a high enough level, and your sponsor has more power than the IT guys.
Problem 3: I don't have a good answer. Sometimes its necessary to just do it and ask for forgiveness - make sure you have an ally (preferably a boss) to protect to from the fallout. SLA's are also a possible fallback -- but it's more beaurocracy. To make matters worse, our IT reorgs every 4 months, and so the department that signed an SLA may not exist to honor it!
Many houses actually have limitted DC or low-voltage "circuits". Examples: Doorbells, thermostat wiring, security systems, some track lighting systems, and landscape lighting. My doorbell circuit (installed many decades ago), for example, has a transformer near the circuit board. This takes power to the doorbell button and various bells. You use low voltage in landscape lighting simply because its much safer -- if you put a shovel through 12V line, noone gets hurt.
However, usage is very limitted and there certainly aren't standard plugs.
I think that a more experienced electrician (while I just wired my house, which only means I have a better appreciation for what I don't know) could explain why 120V / 240 V are better choices for most circuits. It probably has to do with safely and effeciently putting adequate power to the outlet.
I think that the killer of standardization would be that most low-volt and DC systems have transformers because they have very specific volt / current specifications. In order to effectively pump DC or low-volt power around your house, you'd have to convince all electronic manufacturers that they should run their stuff on exactly 12v DC, not 1, 4.8, 5, 6, or 10, or you'd still need a transformer. They might need a transformer anyway, because no responsible manufacture of sensitive electronics would count on municipal power or home-owners' transformers delivering exactly x volts.
Has anyone out their tested out what is available in SQL express as far as job scheduling , DTS (now ETL) and replication? Does anyone want to flame me for unashamedly using MS SQL?
As best as I can tell from their spec sheet, the following features of MSDE 2000 are not available in SQL Express: * No job scheduler in SQL express. SQLAgent worked fine in MSDE 2000. * Replication: MSDE for SQL could public and subscribe (as far as I understand), while SQL Express 2005 can only subscribe. * They've changed the name of DTS to "Enterprise ETL Platform" or SSIS or something. While I haven't tested it out yet, it appears that DTS functionality is limited to basic import and export. For the really useful stuff (DTS to web services, for example) you need the pro edition.
Added: * A user interface. MSDE 2000 basically had none. If you didn't have visual studio, or a developer's license to MSSQL, or some 3rd party administration and query tool, you basically had to use osql (command line). * You get 4GB instead of 2GB.
Now, I have access to a few large corporate MS SQL servers, so this shouldn't really be a problem. However, large corporate servers have complex change-control processes.
Consequently, I rely on the desktop editions for all my ad-hoc stuff, development, and stuff that hasn't quite made it to production. I also run a database for a non-profit on MSDE, and was hoping to keep the replication features while moving up to SQL Express.
Slashdot Mirror
Code needs continuous improvement. Technology wants continuous improvement. Process wants continuous improvement. Agile / lean are the latest improvement. Concepts and patterns want names - buzzwords if you will - so we can agree what we are talking about.
Agile and lean were wildly successful methodologies long before they anointed with a buzzword. Is it crap? Evidenced by the rampant success of Toyota (lean) vs GM (conventional methodology), it is not crap. Agile and lean are not "new" at this point - they are now the minimum bar in most industries. Processes even better than the agile / lean methodologies sure exist. Those companies will thrive and a new buzzword will come into play.
Fortunately for you, you don't have to be interested in process improvement to be a programmer (only code improvement). You do have to be interested to be a successful manager or lead, though.
Double amen.
The article was beautifully insightful - where the rags are just inciting. It actually addresses many of the rags against agile.
Agile thrives when people get past the initial learning curve (past the checklist, as Cockburn points out in the article), re-read the agile manifesto, and intelligently apply the principals.
Cleanroom sounds interesting. Perhaps I hyperbolized if I indicated that TDD is the ONLY method of creating reliable software. It is, however, one of the cheapest and easiest.
"Which is cute, except that a lot of real world software development doesn't fall into neat little boxes like that.."
Not just cute, but very valid. Most real world, usable software can be broken down into neat little boxes, and should, for more reasons that just TDD support. Budgets change, financial systems crash and leave you without credit lines ... Breaking down features into small chunks is necessary to ensure that you produced some value before your product was unexpectedly canceled. That's a principle well beyond TDD. My company has several massive projects going forward rapidly, on budget, broken down into small pieces, just like this. We are less worried then others about change, precisely because, while we have much more to do and many months to do it in, we have we could sell right now. A lot of people believe you can't break this stuff down, don't ... and go out of business when vaporware v2 isn't done on time. We'd just ship 90% of the features as V2.
Also remember TDD is mainly about about unit tests. Your combination argument applies to integration tests, and is the main reason to apply strict TDD (with unit tests). Some math ...
I create components with clearly defined responsibility and few dependencies. It might have 3-4 methods and perhaps 10-100 test cases. In unit tests, this is possible. It's easy enough that you can easily dig into the edge cases for each component.
If we start at integration testing or manual testing, combining 4 or 5 of these components, we have an unmanageable test matrix. You'll never cover the base cases, much less the edge cases.
e.g Just last week, I headed off a subtle bug starting from an incorrect comparison leading to bad sort and on to total badness. After applying a refactoring recipe straight out of most TDD books, I discovered I could get to the edge cases of a sorter very rapidly. The integration test would have required an large and complex test data set. The bug would be lost in the details.
The TDD hypothesis is that you achieve reliability faster by ensuring that each component is extremely reliable, and combining reliable components. Interesting integration cases are the domain of the quality assurance professional. If the components are reliable, QA will have time for interesting testing. If not, they will fill there days filing mindless functional bugs and miss massive problems.
"One of the problems I have with these "experts" ... I won't get into an argument about authority. My point is, most any book or resource about TDD, unit testing, or the like, does not omit the role of manual testing. The back cover of the book might omit it. Most agile methodologies will also combine TDD with continuous integration and rapid, manual, QA cycles. Same idea: get results as fast as possible, fix as fast as possible, know that when you are done, you are really done.
My experience strongly confirms the TDD hypothesis. However, there are dozens of ways to achieve quality. Regarding this book and review: TDD works for many people, for those who buy the TDD hypothesis, Feathers' book is great.
Your argument seems plausible, until you have actually seen the difference in products developed with test-driven / unit test first approaches. The benefits are not what you think they are. I would agree that unit tests are not a panacea, but disagree on
1) The are essential, not just helpful, at least, if you intend to produce software that works.
2) Unit tests do not need to be comprehensive to be useful. They don't need to be great, but great helps.
I tend to agree with you on 1) unit tests are not integration tests, and also do not replace smart human testers. 2) No TDD or agile expert would include the word "anything" in this statement "When good unit tests are in place, then code can be changed at will and the tests will tell automatically you if you broke anything"
Here is what does happen in initial development with TDD / Agile.
First, you write tests first, based on clear user stories. Then you write code to pass to pass tests (one at a time). This saves massive amounts of time: you avoid unnecessary code, over-design, and unnecessary features.
You see a side benefit quickly: In order to get code into true unit tests, each module has to do something meaningful on its own. You avoid the massive stink of excessive interdependency that paralyzes much OO code. (Much of Feather's book is about how to break those dependencies in order to test code).
Now, 1 or 2 weeks later (agile development gives you something interesting to look at in a week or two, not a month or two), it's either time to clean up the code, or you found you really misunderstood the problem. With this test coverage, it is enormously easily to re-factor.
But a warning: If you were writing integration tests (not unit tests), you'll find the tests are in the way. You make 1 change, and 10 tests fail. Done correctly, 1 change, 1 unit test fails. xUnit Test Patterns might be a good book, if you have this problem.
Is the coverage helpful or essential? Most of the code I work on has complexity rated at mind-boggling. Not only is it helpful to have the coverage, it's essential. I don't want to attempt to remember all 200 rules and exceptions when each behavior is complex enough. And don't want to wait 2 weeks for QA to finish their test pass. Good coverage means I make a change, and know immediately. I can let QA know risks that can't be covered in unit tests, and they can do some valuable work in discovery. Essential!
This book has been essential to me over the last 2 years: I've been keeping the "legacy" parts of a large web application running while others went on to develop cool new features. Let's just say this, there are two different challenges in software:
Challenge 1) Create a good design from scratch. Lots of folks can do this.
Challenge 2) Move from bad design or bad code to good design, while keeping the product running. Transforming a design in small re-factoring steps is vastly harder than rebuilding, but usually necessary.
This book is about that second, harder challenge. It emphasizes testing and testability, because that is how you ensure the product continues to run while you make the necessary changes. It does tend to assume you know what the good design you aim for is.
This is a very important book to have on your bookshelf, and will probably not become obsolete soon.
I am so totally making that my motto. In fact, I'm adding it to my sig right now!
I doubt that long term studies have been completed. It doesn't seem like ZIFs are extremely new, this process for creating them and this particular variation are new. That said, several other sources provide better information than the CBC link and speak directly to your question. The CBC article states in first paragraph: "the crystals are non-toxic and would require little extra energy from a power plant."
http://www.sciencedaily.com/releases/2008/02/080214144344.htm/ Suggests that this looks much cleaner than existing state of the art:
Yaghi's initial idea of what to do with the material afterwards appears to involve geologic storage.
It's also always useful to hunt down the primary source. I think this PDF is it (I only skimmed).
Of course, it's always entertaining to imagine how much better I could run the country. If you were going to pick an SLDC as a hypothetical model, I would prefer models based on Agile Principles, perhaps with some scrum. These would also address the concern of time. Some of the characteristics of such a system might be:
Many posts are correct that the challenge is sale and buy-in. I'll just chime in to agree that media wikis are transformative. Valuable documentation is documentation that is easy to find and kept up to date.
I've seen the following set up with little success at previous companies
Media wiki: Easy and cheap to set up. Easy to find stuff. Anyone can update to correct inaccuracies (or roll back incorrect edits). We combine it with a local Google search Appliance and I can find anything I need in seconds. I can't imagine documenting process, or anything else, in any other way.
The approach discussed works on "... a simple premise: driving somewhere usually requires crossing major intersections that are sparsely interconnected. "
Ask yourself frankly, was I just slacking, or did I not get it?
... what do I do about this?
If you were just slacking the first time around, most of the posts in this forum are applicable. Take classes, get texts, etc. Just set reachable goals and keeping whacking away at them. Classes will keep you on track.
If you genuinely had trouble with it, the first or second book in your scheduled reading might actually be in cognitive science, pedagogy and so forth. Various fads have swept the nation in math education. Ignore the fads and you'll find most of the basics are the same. Anyway, young kids have a learning advantage in many ways, but adults can understand how to learn something, which can make all the difference. Just for example, part of maturation is better skills at handling frustration. When you hit sticking points, you will have the ability to say: why am I confused? What part of this problem is hard and what part is easy? OK
Hear! Hear!
I love my 20 minute afternoon power nap. If you are face down on the keyboard it looks like falling asleep on the job. I stretch out on the floor with a pillow to make it clear I'm recuperating, not lazy! In all other matters, I attempt to maintain a more "proper" demeanor.
Driving efficiently needs to be made as cool as driving aggressively. There are "hypermiling" competitions out there for who can get the best gas mileage through an in-city route.
i ng_of_the_hypermilers.html?welcome=true
Here's an article about a guy who takes it a little too seriously: http://www.motherjones.com/news/feature/2007/01/k
I've tried driving for excessive fuel economy and found it a fun challenge. If you need to feel "cool", cornering at high speeds to avoid braking. There's the challenge of knowing exactly when to start coasting to pull to a stop at home without braking or accelerating. I'm getting c 32 MPG in-city these days on a car rated at 24MPG in city. Hope to break 40 MPG at some point.
My personal preferences align with your statements, but I doubt it will make any difference in the battle of Google vs MS. Money will matter. I also think that the Slashdot has picked up a red herring in the author's statements about Click - Once and the VM.
.NET applications can't run on 5% of desktops. Will that 5% affect the MS bottom line? Not much.
.NET rich apps becomes a barrier if you a bank providing access to customers. (It's a small annoyance if you are a corporate IT shop. )
.NET the business model is flawed? No. It's obvious that MS is very aware of that the problem that public web sites won't start using .NET rich UI's extensively. Consequently, MS pushes their web (ASP) framework much harder than their rich UI tools. Frankly, it's almost as if Winforms is an afterthought in visual studio. MS can make plenty of money off IIS / ASP / Sharepoint and other server technologies that provide access to clients running any platform with a reasonably modern browser and the ability to run javascript.
While interoperability is a much stronger technical argument than Security and some of the other cases made in this discussion, is it a business argument?
OK, we can point out that we see almost no end-user oriented web sites using web-deployed Rich UI, or click once technologies. That 5% of machines can't run
Does this mean that
Where's the interoperability problem in MS development software? More specifically, is there an interoperability problem that will affect their revenue at all? No, there isn't.
Like most of the Slashdot readership, I'd personally prefer that the technology that "wins" is the best technical solution, that it will run on any machine in any form, etc. However, the beauty of a technology doesn't make a business case. A vast number of technology companies died in the late 90's partly because they failed realize that end users' cash pays for their products, not the admiration of other nerds.
I won't go on to discuss how this applies to the Google v MS fight. The article author failed to explain how a company that makes most of it's money off advertising competes with a company that makes most of it's money off software license fees, so I'm not sure where to start.
Can't agree more that external hard drives are the way to go for home users. I'd suggest two for anyone with data of any value.
... not shifting out 200 obsolete CD's onto 50 DVD's every couple of years.
/e /d in 1-10 minutes over USB 2.0. (Linux geeks may point out the vastly superior Unix options). I'd like something with a little better differencing, but xcopy works for me.
CD/DVDs:
- Not big enough. I end up with too many disks.
- Too slow - I never get around to backing stuff up.
- Probably won't be readable in 10 years (disk will degrade, if readers are available).
- They are still great for sending Grandma pictures of her Great-Grandkids.
Prefered:
0. Data must be on 1-2 disks, no more.
1. 2 big external drives.
2. Second drive is always two years newer.
3. Keep copying data forward to new drives.
4. Do you really need backup software?
Data on just one- two disks: Any backup that requires switching disks won't get done. Besides, I wouldn't be able to find my stuff in 100 disks from the last 10 years.
Keep 2 Devices: I tend to carry my external drive around. While this means its safe from fire at home, it also gets abused. So, I need two backup drives. If you're really paranoid, keep one in a safe deposit box.
Second drive is newer / copy data forward onto new drives: This is the key to the longevity. I demand that my data storage system ensure that children have access to their baby pictures 20 years from now. The data won't be available if it's on any medium which will be obsolete in the future. This is any medium (hard drive, cd, etc) currently in use, except paper and stone tablets. To solve this, I plan on buying a new disk every 2 years, and copying data forward onto newer drives. To be practical, this should be one copy operation
The copy-forward solution also prevents inevitable degradation of the disk. CD's will probably have died in 10-20 years - or gotten lost. I've got some compositions from the 1990s on floppy disks that are (fortunately?) lost to the world.
Do you need backup software? I suppose backup software is useful, but I can currently execute xcopy "[location of my stuff]" "[external drive]"
Do you sometimes wonder why MS has purchased and is investing in virtualization technology? A compelling strategic / tactical reason would be to leverage it to break out of the backwards compatibility problem.
.NET framework gives them the abstraction layer they need to make this work with existing code and without virtualization. You can run .NET code in Mono on Linux ... it should be trivial to make it work in a different Windows OS. Currently, there are only small sets of features you lose when running .NET on old windows versions ... and the framework usually handles these very gracefully. No XP styles? Use a default color ... etc.
... but since when did MS care about that? They have more bundling and anti-trust problems to deal with by integrating another product into the OS ... but MS seems to prefer throwing lawyers at this type of problem.
They certainly aren't doing this so that you can run Linux on Windows. That would reduce switching costs and be bad strategy. Buying virtualization could be just another niche market or attempt to fill the product space - but that's not hugely compelling. It doesn't look like they bought the product to kill it. If that were the case, they'd also need to buy VMWare.
Here's one scenario: Once their virtualization technology is stable (almost there?), they integrate it into their OS. Windows NT 7 (is Windows Vista NT 6 or NT 5.x?) could totally break backwards compatibility, and run old apps in a virtualization layer running the old OS. Maybe NT 7 will include machines and API's optimized and tested to run each specific previous release of Windows.
Pushing the
Indigo style communications layers could theoretically even make communication between a virtuallized Win2K and the theoretical host OS possible, particularly if the virtualization technology is embedded and integrated in the OS. OK, it'd be slow
An excellent list that engineers would understand. To this I'd add:
System / Integration testing: Periodically run your document by one of the people in its audience. Make sure that your point comes across accurately, and that they can easily find the information that they want. This is a very fast way to learn what works and what doesn't work in communication techniques.
Work with users to determine feature prioritization: Create an outline for project documentation, and ask project team - which headings will you actually use? Delete the other headings and save yourself time. This makes for a more concise document, which is more likely to be read.
While stating "deliberately held back a security patch" might be factually correct and a good catch line, I think it's highly misleading: it directs the reader towards many of the wrong conclusions.
Later in the article: "Officials -- not unreasonably, say security experts -- wanted to test the patch before installing it." Well, duh. This is the interesting story. They couldn't get through the tests that they SHOULD do fast enough.
The problem is agility and testability of the systems and deployment. The easiest solution has nothing to do with MS, nothing to do with windows, and everything to do with giving your test group more respect and resources.
This is not a problem inherently Microsoft's making. You can argue up and down that patches should be faster, product more secure etc. In the end, it's plausible that discovery, patch, exploit can come with bad timing in any system. System admins and project managers that don't plan for this are asking for trouble.
Elaboration: I push very hard to ensure that all my products have automated tests. My company's Desktop Engineering department requires automated tests of all its myriad apps (DE is not my department, won't take credit). I force redesign if a product can't be tested cheaply. The benefit is: I need new feature x tomorrow (maybe some suprise regulation) or company needs patch y tomorrow (e.g. Zotob worm). Where we've achieved our test automation goals (haven't in all cases, but our coverage is good enough), we can hit a few buttons, run our tests. Repeat on all 20 configurations / platforms. 90% of the time, we find no problems, and can deploy. If it's critical, you take the risk and deploy. If not, you go on to slower manual testing to complete coverage.
Had this US-VISIT program implemented adequate and automated tests, they could have deployed in a few days, not a few weeks. The methods and tools to do so have nothing to do with Microsoft. They don't even make the type of test automation tool required for this - although I know they have one for internal use.
As part of their release, they have a contest with some useless prizes. The interesting bit is that they are encouraging me to use open source licensing (see "Rules" section):
In addition to submitting your Mash-Ups via the submissions process described above, you must host the source code for each of your submitted Mash-Ups.... You may make the source code for your Mash-Ups available under the license of your choice. However, we encourage you to make the source code available under a BSD-style license, such as the Academic Free License, the Apache License 2.0, the New BSD license, or the MIT license...Anyone care to explain the term "mash-up" to me?
The information you requested is in the third paragraph of the article, albiet not in depth. It describes types of jobs expected to grow in the U.S.
"...the U.S. IT sector's overall growth should outpace that loss of jobs, expanding opportunities for those trained in fields such as software architecture, product design, project management and IT consulting..."
Later, the article names some specific industries:
"... there will be continued growing demand for IT as underserved fields such as health care, retail trade, construction, and certain services make greater investment in technology."
I swear this could be someone in my team. Hell, it could be me. Your screen name is my real name. Frightening. This is the same world I live in.
Some problem definitions:
Problem 1: Territory
Central IT has a valid objective of maintaining standards for the purpose of security, etc. They do not have a valid mandate to do all the work themselves, if they can't do it to your timeline.
Problem 2: Power and influence
Outside IT, it may appear that you don't have the necessary influence to force change on IT. e.g. I could save my company bundles by putting in a real middleware solution, but don't have to influence to push it.
Problem 3: Non-lean processes
Many beaurocratic processes don't add value. This is where we get frustrated. You needed your RAM now, but it got delivered 9 months from now. My IT department saved me 5% on the cost of dev tools -- after 10-20 staff hours of meetings (at >$50 per person per hour = $500-$1000) that wiped out all benefits.
Approach to problem 1:
Recognize that the IT department has a valid mandate to enforce security and other guidelines. Include them as stakeholders in planning, but reach a compromise where you can implement yourself. IT validates that product X is a good thing and adds their requirements. I'll go buy it and install it on my own, thanks. This can save months waiting for some bean pusher to remember to send a purchase order out.
Practice this yourself: never insist on doing something yourself, if someone else is perfectly capable.
Approach to problem 2:
Get sponsorship at the highest level you can. You'll be suprised at the results you can get. IT is a cost center. If you don't report to IT, you probably represent a department that earns the company money. Getting sponsorship at a high enough level, and your sponsor has more power than the IT guys.
Problem 3:
I don't have a good answer. Sometimes its necessary to just do it and ask for forgiveness - make sure you have an ally (preferably a boss) to protect to from the fallout. SLA's are also a possible fallback -- but it's more beaurocracy. To make matters worse, our IT reorgs every 4 months, and so the department that signed an SLA may not exist to honor it!
I'm convinced that the artic is cold, because eskimos have so many words for snow.
Time to factor in the settlement of Alaska by Anglophones into global warming.
(I know subsequent posts point out the fallacy of the premise, but true premises aren't really necessary in erroneous arguments.)
I didn't really see benchmarks (performance comparisons) in this article. This article was a review and feature comparison.
Many houses actually have limitted DC or low-voltage "circuits". Examples: Doorbells, thermostat wiring, security systems, some track lighting systems, and landscape lighting. My doorbell circuit (installed many decades ago), for example, has a transformer near the circuit board. This takes power to the doorbell button and various bells. You use low voltage in landscape lighting simply because its much safer -- if you put a shovel through 12V line, noone gets hurt.
However, usage is very limitted and there certainly aren't standard plugs.
I think that a more experienced electrician (while I just wired my house, which only means I have a better appreciation for what I don't know) could explain why 120V / 240 V are better choices for most circuits. It probably has to do with safely and effeciently putting adequate power to the outlet.
I think that the killer of standardization would be that most low-volt and DC systems have transformers because they have very specific volt / current specifications. In order to effectively pump DC or low-volt power around your house, you'd have to convince all electronic manufacturers that they should run their stuff on exactly 12v DC, not 1, 4.8, 5, 6, or 10, or you'd still need a transformer. They might need a transformer anyway, because no responsible manufacture of sensitive electronics would count on municipal power or home-owners' transformers delivering exactly x volts.
It appears that MS has done some interesting feature shuffling in their various free editions.
m pare-features.mspx
http://www.microsoft.com/sql/prodinfo/features/co
Has anyone out their tested out what is available in SQL express as far as job scheduling , DTS (now ETL) and replication?
Does anyone want to flame me for unashamedly using MS SQL?
As best as I can tell from their spec sheet, the following features of MSDE 2000 are not available in SQL Express:
* No job scheduler in SQL express. SQLAgent worked fine in MSDE 2000.
* Replication: MSDE for SQL could public and subscribe (as far as I understand), while SQL Express 2005 can only subscribe.
* They've changed the name of DTS to "Enterprise ETL Platform" or SSIS or something. While I haven't tested it out yet, it appears that DTS functionality is limited to basic import and export. For the really useful stuff (DTS to web services, for example) you need the pro edition.
Added:
* A user interface. MSDE 2000 basically had none. If you didn't have visual studio, or a developer's license to MSSQL, or some 3rd party administration and query tool, you basically had to use osql (command line).
* You get 4GB instead of 2GB.
Now, I have access to a few large corporate MS SQL servers, so this shouldn't really be a problem. However, large corporate servers have complex change-control processes.
Consequently, I rely on the desktop editions for all my ad-hoc stuff, development, and stuff that hasn't quite made it to production. I also run a database for a non-profit on MSDE, and was hoping to keep the replication features while moving up to SQL Express.