I felt sorry when I heard that the Robot Animal Within is nearing terminal status, both physically and financially. I have read many of his books and have always considered him to be of great merit in the libertarian free thinker category. I met him once and found that he had a deep, spiritual quietude.
I would donate if I thought that the money could actually help the author instead of his creditors.
In my shop, our weakest bits are our third party components. However, we would not be as far along as we are without these components. This is also nothing new. Components have been around for a long, long time. The first place where components took off was GUI. When's the last time you wrote a message pump? Books like Better, Faster, Lighter Java and the push towards SOA are all about reusable components. The move now is to componentize the business tier. BPEL and YAWL are technologies that attempt to make it easy to publish and consume business process components. Assembling components is about build versus buy and accelerating schedules and it is also about reducing complexity (reducing maintenance costs) because good component based development (whether yours or someone elses) reduces coupling.
I remember attending a product launch video for Windows ME. One marketing droid after another got up to evangelize about this product's greatness. The video audience of marketing flaks cheered with each feature description and demo. Then Gates got up to talk. Basically, he bashed the product and told the audience not to bother. Did I not mention that this was a Microsoft sponsored product launch video? You could hear a pin drop as he left the stage. It most probably took 30 seconds for the next marketing droid to get his enthusiasm back up to required fever pitch.
I took a segway tour this year while on holiday. I had never been on one before. In the 30 minute pre-tour class, the guide explained why G.W. fell off. Basically, he neglected to turn it on to balance mode. Rule # 1 is don't step on until you see the smiley face.
It was fun but I prefer riding a bicycle because you get zero exercise on a segway. It's heartening to hear you describe how it is useful to the disabled. My mother loves to travel to foreign cities where she spends days walking. She is too old to do that so I was thinking that she could rent a segway instead. Do you think that the segway would be useful for the elderly too?
requirements analysis, specification development... if you get that stuff done, the actual coding ought to be an academic exercise
If only it were that easy. Here is what I have found.
The company selects certain employees as the Subject Matter Experts.
Those employees are good at their jobs so they have demonstrated success in the very positions that the proposed software will serve.
Just because you are good at what you do doesn't neccessarily mean that you are good at specifying software features and requirements.
These people spend a lot of company resources doing the business modeling, requirements, and analysis up front and developing possibly CMM-I level 5 compliant documentation only to find that the application still doesn't add a lot of value for its intended audience.
That is why the XP folks are so down on the pre-coding steps. They figure that most companies won't do it right anyway so why bother doing it at all? If I have to re-write the code seven times with or without the inception phase, then you might as well do away with the inception phase and save yourself at least that expense.
That is why ITG is starting to take off. They recognize that just empowering the SMEs isn't going to bring the neccessary product and project management experience to the decision maker's table for a successful launch.
This I believe. It is always a good idea to continue to refine whatever processes, methodologies, and tools you use in the production of quality software. However, no amount of process, methodology, or tool upgrades are a satistactory replacement for human ingenuity in the solution of the very compelling problems that software development faces today.
The question isn't how long does it take to do feature X? but rather what part of feature X can go into the next build? After the users see it, they're going to want to change it anyway. It's not poor estimates that make a project late, it is the inevitable score creep that happens when users see what they asked for in action only realize that it isn't what they really need. This approach is what agile development is all about. They call it time boxing.
It doesn't answer the all important business question when will it be ready? Instead of trying to answer that, find out when they really need it. Not when they want it because they want it now. Not when they tell you they really need it because that answer is going to be part of the same negotiation game (you know, double the estimate, half the deadline) that other posters are playing in their advise in this forum. Find out the external driver that this new feature or product is tied to and take a good guess at calendar dates tied to watershed events in that driver. We will call that the delivery date. Once you arrive and get achieve buy in for a real delivery date with the decision makers...
Estimate how long it will take to fix all bugs in the system once the feature set is frozen.
Use that estimate to back out a feature set freeze date from the delivery date.
Publish this schedule so that everyone understands it and agrees to abide by it.
Identify the key users whose opinions the decision makers trust.
Do a weekly build and make sure that these key users get to play with it every week.
When the feature set freeze date occurs, accept no more scope changes.
They will try to sneak scope changes into the bug list so you will have to inspect carefully and be prepared to reject those bugs.
There will be massive amounts of escalation. He who blinks first looses.
Make a lot of election year promises about how their important feature will get into next year's release.
Take the team out for dinner when you deliver on time.
Will everyone like it? No, your job is not to please everyone. Will you have formed some enemies from this? You bet you will. I would rather be hated on a successful project then loved on a failure. Some of you might say it won't be a success if it doesn't solve the user's pain points even if it is delivered on time. To that I say, if they can't figure out what they need for it to do in six months, then they will never be able to figure out what they need for it to do.
Once you gain sufficient experience estimating development work in a particular platform, architecture, language, library, domain and seeing how close actual delivery is to the estimate, you will be able to satisfactorily predict when you can deliver on a particular specification but only if the specification is non-ambiguous, non-contradictory, and complete enough such that you will not need any further clarification.
You will be able to answer the "how long will it take to implement this feature as spec'd?" questions. What you will not be able to answer is the "how long until we can release the software to its users?" questions. It is the latter question that is of most interest, yet no amount of technical expertise can address it.
Email encryption and certification gathers in efficacy in direct proportion to its ubiquitousness. PGP Home costs $99, which no casual user to going to pay, and GPG asks questions, during the key set up, which your casual user is not going to understand. Distributing your public key can also have lots of "gotchas" that requires too much thinking for the casual user.
I am an advocate of a free and easy to use encryption and certification technology for sending and receiving trusted emails that cannot be intercepted. I believe that a free, single page "GPG for Dummies" PDF would be great.
I, too, am a big fan of mind mapping and am familiar with different mind mapping applications although not the one that you reference. I find mind mapping to be great for organizing ideas. It is sort of an outline on steroids. However, I don't see how mind mapping is very helpful in presenting rectilinear information. How do you use this product to present a table of information?
The original poster was considering sharepoint but found it lacking. I would totally agree that plone might be just what the original poster is looking for. It is easy to integrate your own apps into this CMS by writing your own document types (called archetypes) and skinning them using TAL. Aggregate, navigation, or reporting pages can be easily cooked up with a little python script and skinned by TAL.
Your focus shouldn't be on tracking and staying on top of all the trends.
The original poster wants to stay on top of trends. I mean no offence but is it really your place to dictate to the original poster his or her interests?
A heads down coder doesn't need to be on top of the latest trends but an architect does. When asked why a certain technology was included or omitted, the architect should be able to give a knowledgable answer in order to be perceived as credible. An answer of ignorence (i.e. I never heard of that) doesn't buy you much credibility.
I hear you. I was speaking not from a technology perspective but from career perspective.
The U.S. I.T. industry is no longer a place where the average employee can expect to work a single job until retirement. Every job that you work will have a beginning, a middle, and an end. For a smoother experience in life, you should be planning for all three transitions.
Before you accept an offer of employment, you should ask yourself this. What will my resume look like when I am ready to move on from this job? Will my skillset be marketable? Will I be able to compete with other job seekers at that time?
If you are taking a VB 6 position, then years down the line when you are ready to move, you will be locked into that position because who would hire a VB 6 developer unless they only need VB 6 development? Over time, there will be fewer and fewer VB 6 coding opportunities.
That is why staying with VB 6 is a bad idea. Not because of technology but because it will be hard to staff a VB 6 position. You will be fighting Microsoft's own marketing engine which is not a good place to be.
Right. The success of their office productivity suite will make it very hard for Microsoft to transition to SaaS as a company wide business model. They can certainly create new revenue streams in a SaaS model but they have too much investment in software for the client's machine to ever truly embrace the thin-client approach that makes sense for SaaS.
A properly trained professional with advanced experience will write a better product.
Correct! For the same reason why you don't hire a chef to renovate your kitchen, you don't hire an accountant to write your accounting package. The accountant can be interviewed to determine functionality but has no competency in making technical decisions.
you can find more VB programmers than C# programmers
Not in the Southeast of the USA. If you want to be able to attract experienced and talented developers to your team, then you should choose C# over VB.NET as your development language. We all know that, technically speaking, the language differences are minimal outside of syntax. However, the perception is that VB, in all its forms, is for hobbiests and wannabes. Serious developers want to be taken seriously so they avoid VB.NET
By the way, if the owner wants the code rewritten in VB6, then he's a fool. No serious developer would be caught dead in that job lest he wake up one day to find himself in the same predicament as the cobolers.
I must have lower expectations than you or, perhaps I think more like the original developers because I use most of the applications you list but don't run into that much data loss or crashes.
every major MS Office application - I haven't run into data loss or crashes in years, however, I am not a heavy user. I pretty much limit myself to reading use/case docs or resumes with this stuff. MS-Project is pretty buggy these days, especially Project Server
all recent versions of Internet Explorer on Windows - You got me on that one. Way too insecure for casual Internet usage.
all recent versions of Visual Studio - Oh, yea, I forgot how bad that is. I usually use emacs and nant.
Paint Shop Pro X - It's been a long time since I used PSP but I don't remember any data loss or crashes.
countless games - I'm not a big gamer. It takes me years to get through a modern game. I'm still on Serious Sam II. No crashes to date.
every major OpenOffice application - This is what my whole family uses at home. No crashes or data loss.
Firefox - No crashes with recent versions.
Thunderbird - Yea, there's still room for improvement here.
Scribus - I don't know this one. It looks interesting. I'll have to check it out.
the GIMP - Recent versions have been pretty solid. Keep in mind, however, that their love is with Linux. The Windows build is most definitely the fair haired step-child.
several LaTeX packages - I don't know which packages you are talking about but you are most probably right about that. I hope that you are not judging LaTeX to be bad just become someone cooked up a package and distributed it on the web. A lot of that kind of stuff is itch scratching and publishing online without a lot of time spent on quality or polish.
most software quality today sucks and we could do much better
Really? I use a lot of different software and I don't share your perception at all. Of course, I use a lot of open source software which could be of higher quality.
Are there any specific titles that you are thinking of? From that list of titles, which ones have you read their design specs?
The end user doesn't get access to the internal design specs for most software so you can't help but "muddy the waters" when it comes to making a judgment on a particular software's quality.
If that is the case, then I must reverse my position. In fact, it becomes trivially easy to ship a bug free application. Simply remove or rewrite all parts of the designer's spec in such as way as to eliminate any gaps between the finished program's behavior and what is documented there for those bugs judged as too risky to remove at this time. You can move those parts of the designer's spec to a "future release" version of the designer's spec.
While resources such as Wikipedia define the term "bug" as you do, an example of a resource that takes the bigger picture view on what a bug is is Steve McConnell's book Code Complete.
I suppose that Knuth has a very "computer science" definition of what a bug is whereas the guy that I was quoting has a "marketing" definition of what a bug is. To marketing, a bug is something wrong with the application. So, a missing or mis-perceived feature could be a bug. If my previous head of marketing were ever to encounter TeX, I would guess that the first "bug" he would find is the lack of WYSIWYG.
I, myself, have used LaTeX and have not been able to get word wrap within a tabular block to work. Whether or not there is something I am doing wrong or there is an elegant explanation as to why you should never do that is irrelevant to me. I would like that and I can't get it, so it feels like a bug.
I remember attending a meeting at a conference held by one of my previous companies. The head of marketing had this to say. All software has bugs. If it doesn't have bugs, then it isn't software. So true.
Keeping markup out of your code means that you can, for example, bring in a graphic designer to change the look and feel your site/app without requiring that they know Perl
In my humble opinion, it should be the objective of the web developer to develop a web application where the markup is so well designed that the graphic designer need only modify the CSS file in order to make whatever changes he or she requires of the web site's look and feel. Given a modern browser, you can get 80% there without trying real hard.
I originally learned about the Zen Garden from another/. post. This is well worth studying to learn about good markup design from the standpoint of decoupling GUI from markup generation.
The posters in this topic don't differentiate between content and markup. I am assuming that they are really interested in discussing the pros and cons of embedding markup in the code.
Right. I run into this every time when I want to switch from portrait to landscape. The OO way is okay but I have a lot of difficulty remembering how to do it because it is different from the MS-Word way. Their help system explains how so it is not a big deal.
Slashdot Mirror
I felt sorry when I heard that the Robot Animal Within is nearing terminal status, both physically and financially. I have read many of his books and have always considered him to be of great merit in the libertarian free thinker category. I met him once and found that he had a deep, spiritual quietude.
I would donate if I thought that the money could actually help the author instead of his creditors.
This blog is cute with the "good agile, bad agile" gimmick. A more intelligent and insightful treatment of the issue can be found here, however.
In my shop, our weakest bits are our third party components. However, we would not be as far along as we are without these components. This is also nothing new. Components have been around for a long, long time. The first place where components took off was GUI. When's the last time you wrote a message pump? Books like Better, Faster, Lighter Java and the push towards SOA are all about reusable components. The move now is to componentize the business tier. BPEL and YAWL are technologies that attempt to make it easy to publish and consume business process components. Assembling components is about build versus buy and accelerating schedules and it is also about reducing complexity (reducing maintenance costs) because good component based development (whether yours or someone elses) reduces coupling.
I remember attending a product launch video for Windows ME. One marketing droid after another got up to evangelize about this product's greatness. The video audience of marketing flaks cheered with each feature description and demo. Then Gates got up to talk. Basically, he bashed the product and told the audience not to bother. Did I not mention that this was a Microsoft sponsored product launch video? You could hear a pin drop as he left the stage. It most probably took 30 seconds for the next marketing droid to get his enthusiasm back up to required fever pitch.
I took a segway tour this year while on holiday. I had never been on one before. In the 30 minute pre-tour class, the guide explained why G.W. fell off. Basically, he neglected to turn it on to balance mode. Rule # 1 is don't step on until you see the smiley face.
It was fun but I prefer riding a bicycle because you get zero exercise on a segway. It's heartening to hear you describe how it is useful to the disabled. My mother loves to travel to foreign cities where she spends days walking. She is too old to do that so I was thinking that she could rent a segway instead. Do you think that the segway would be useful for the elderly too?
If only it were that easy. Here is what I have found.
- The company selects certain employees as the Subject Matter Experts.
- Those employees are good at their jobs so they have demonstrated success in the very positions that the proposed software will serve.
- Just because you are good at what you do doesn't neccessarily mean that you are good at specifying software features and requirements.
- These people spend a lot of company resources doing the business modeling, requirements, and analysis up front and developing possibly CMM-I level 5 compliant documentation only to find that the application still doesn't add a lot of value for its intended audience.
That is why the XP folks are so down on the pre-coding steps. They figure that most companies won't do it right anyway so why bother doing it at all? If I have to re-write the code seven times with or without the inception phase, then you might as well do away with the inception phase and save yourself at least that expense.That is why ITG is starting to take off. They recognize that just empowering the SMEs isn't going to bring the neccessary product and project management experience to the decision maker's table for a successful launch.
This I believe. It is always a good idea to continue to refine whatever processes, methodologies, and tools you use in the production of quality software. However, no amount of process, methodology, or tool upgrades are a satistactory replacement for human ingenuity in the solution of the very compelling problems that software development faces today.
I searched for http://www.mono-project.com/ on http://www.ohloh.net/ and the only relevant hit I found was Qt#. Imagine that.
The question isn't how long does it take to do feature X? but rather what part of feature X can go into the next build? After the users see it, they're going to want to change it anyway. It's not poor estimates that make a project late, it is the inevitable score creep that happens when users see what they asked for in action only realize that it isn't what they really need. This approach is what agile development is all about. They call it time boxing.
It doesn't answer the all important business question when will it be ready? Instead of trying to answer that, find out when they really need it. Not when they want it because they want it now. Not when they tell you they really need it because that answer is going to be part of the same negotiation game (you know, double the estimate, half the deadline) that other posters are playing in their advise in this forum. Find out the external driver that this new feature or product is tied to and take a good guess at calendar dates tied to watershed events in that driver. We will call that the delivery date. Once you arrive and get achieve buy in for a real delivery date with the decision makers...
Will everyone like it? No, your job is not to please everyone. Will you have formed some enemies from this? You bet you will. I would rather be hated on a successful project then loved on a failure. Some of you might say it won't be a success if it doesn't solve the user's pain points even if it is delivered on time. To that I say, if they can't figure out what they need for it to do in six months, then they will never be able to figure out what they need for it to do.
Once you gain sufficient experience estimating development work in a particular platform, architecture, language, library, domain and seeing how close actual delivery is to the estimate, you will be able to satisfactorily predict when you can deliver on a particular specification but only if the specification is non-ambiguous, non-contradictory, and complete enough such that you will not need any further clarification.
You will be able to answer the "how long will it take to implement this feature as spec'd?" questions. What you will not be able to answer is the "how long until we can release the software to its users?" questions. It is the latter question that is of most interest, yet no amount of technical expertise can address it.
Email encryption and certification gathers in efficacy in direct proportion to its ubiquitousness. PGP Home costs $99, which no casual user to going to pay, and GPG asks questions, during the key set up, which your casual user is not going to understand. Distributing your public key can also have lots of "gotchas" that requires too much thinking for the casual user.
I am an advocate of a free and easy to use encryption and certification technology for sending and receiving trusted emails that cannot be intercepted. I believe that a free, single page "GPG for Dummies" PDF would be great.
I, too, am a big fan of mind mapping and am familiar with different mind mapping applications although not the one that you reference. I find mind mapping to be great for organizing ideas. It is sort of an outline on steroids. However, I don't see how mind mapping is very helpful in presenting rectilinear information. How do you use this product to present a table of information?
You must have a lot of experience in it. I have a question for you. How do you turn on automatic word wrapping in a tabular block?
The original poster was considering sharepoint but found it lacking. I would totally agree that plone might be just what the original poster is looking for. It is easy to integrate your own apps into this CMS by writing your own document types (called archetypes) and skinning them using TAL. Aggregate, navigation, or reporting pages can be easily cooked up with a little python script and skinned by TAL.
The original poster wants to stay on top of trends. I mean no offence but is it really your place to dictate to the original poster his or her interests?
A heads down coder doesn't need to be on top of the latest trends but an architect does. When asked why a certain technology was included or omitted, the architect should be able to give a knowledgable answer in order to be perceived as credible. An answer of ignorence (i.e. I never heard of that) doesn't buy you much credibility.
I hear you. I was speaking not from a technology perspective but from career perspective.
The U.S. I.T. industry is no longer a place where the average employee can expect to work a single job until retirement. Every job that you work will have a beginning, a middle, and an end. For a smoother experience in life, you should be planning for all three transitions.
Before you accept an offer of employment, you should ask yourself this. What will my resume look like when I am ready to move on from this job? Will my skillset be marketable? Will I be able to compete with other job seekers at that time?
If you are taking a VB 6 position, then years down the line when you are ready to move, you will be locked into that position because who would hire a VB 6 developer unless they only need VB 6 development? Over time, there will be fewer and fewer VB 6 coding opportunities.
That is why staying with VB 6 is a bad idea. Not because of technology but because it will be hard to staff a VB 6 position. You will be fighting Microsoft's own marketing engine which is not a good place to be.
Right. The success of their office productivity suite will make it very hard for Microsoft to transition to SaaS as a company wide business model. They can certainly create new revenue streams in a SaaS model but they have too much investment in software for the client's machine to ever truly embrace the thin-client approach that makes sense for SaaS.
Correct! For the same reason why you don't hire a chef to renovate your kitchen, you don't hire an accountant to write your accounting package. The accountant can be interviewed to determine functionality but has no competency in making technical decisions.
Not in the Southeast of the USA. If you want to be able to attract experienced and talented developers to your team, then you should choose C# over VB.NET as your development language. We all know that, technically speaking, the language differences are minimal outside of syntax. However, the perception is that VB, in all its forms, is for hobbiests and wannabes. Serious developers want to be taken seriously so they avoid VB.NET
By the way, if the owner wants the code rewritten in VB6, then he's a fool. No serious developer would be caught dead in that job lest he wake up one day to find himself in the same predicament as the cobolers.
I must have lower expectations than you or, perhaps I think more like the original developers because I use most of the applications you list but don't run into that much data loss or crashes.
Really? I use a lot of different software and I don't share your perception at all. Of course, I use a lot of open source software which could be of higher quality.
Are there any specific titles that you are thinking of? From that list of titles, which ones have you read their design specs?
The end user doesn't get access to the internal design specs for most software so you can't help but "muddy the waters" when it comes to making a judgment on a particular software's quality.
If that is the case, then I must reverse my position. In fact, it becomes trivially easy to ship a bug free application. Simply remove or rewrite all parts of the designer's spec in such as way as to eliminate any gaps between the finished program's behavior and what is documented there for those bugs judged as too risky to remove at this time. You can move those parts of the designer's spec to a "future release" version of the designer's spec.
While resources such as Wikipedia define the term "bug" as you do, an example of a resource that takes the bigger picture view on what a bug is is Steve McConnell's book Code Complete.
I suppose that Knuth has a very "computer science" definition of what a bug is whereas the guy that I was quoting has a "marketing" definition of what a bug is. To marketing, a bug is something wrong with the application. So, a missing or mis-perceived feature could be a bug. If my previous head of marketing were ever to encounter TeX, I would guess that the first "bug" he would find is the lack of WYSIWYG.
I, myself, have used LaTeX and have not been able to get word wrap within a tabular block to work. Whether or not there is something I am doing wrong or there is an elegant explanation as to why you should never do that is irrelevant to me. I would like that and I can't get it, so it feels like a bug.
As he or she is in group 2.
I remember attending a meeting at a conference held by one of my previous companies. The head of marketing had this to say. All software has bugs. If it doesn't have bugs, then it isn't software. So true.
In my humble opinion, it should be the objective of the web developer to develop a web application where the markup is so well designed that the graphic designer need only modify the CSS file in order to make whatever changes he or she requires of the web site's look and feel. Given a modern browser, you can get 80% there without trying real hard.
I originally learned about the Zen Garden from another /. post. This is well worth studying to learn about good markup design from the standpoint of decoupling GUI from markup generation.
The posters in this topic don't differentiate between content and markup. I am assuming that they are really interested in discussing the pros and cons of embedding markup in the code.
Right. I run into this every time when I want to switch from portrait to landscape. The OO way is okay but I have a lot of difficulty remembering how to do it because it is different from the MS-Word way. Their help system explains how so it is not a big deal.