In ancient times, we used to call that sort of thing "wallpaper code" because you could print it out and stick it...well, you know.
I'm surprised that anyone under 65 years old still writes code that way. I guess it goes to show George Santayana was right whe he said, "Those who cannot remember the past are condemned to repeat it."
Dave_Nicolette
@Dave_Nicolette
Best posts made by Dave_Nicolette
Latest posts made by Dave_Nicolette
-
RE: Biggest bottleneck fix in human history
-
RE: Career in programming?
>most WTFs I make are out of laziness or apathy
You may not want to emphasize those traits in your resume.
Just a thought. -
RE: Agile Layout
@R.Flowers said:
THE INVENTOR OF XTREME-ANYTHING SHOULD BE KILLED DEAD TO DEATH WITH A BIG SAWN-OFF SHOTGUN.
I don't think you're drinking enough Mountain Dew.
Whatever happened to Jolt Cola?
-
RE: Career in programming?
n89j and Jordan,
I doubt it's possible to predict what the future of computer-related work holds with any degree of accuracy. Things change rapidly. I can offer one suggestion - hook up with your peers in person, at conferences, and online. Participate in "the community" (whatever that means) so you'll be aware of what areas seem to be growing at any given time, and help each other get ahead. Good luck! -
RE: More on Extreme Programming
>The Agile blog describes the planning
method required for Agile. Incidentally, it's the planning method
required for ALL large projects.
Sorry I neglected to address this point earlier. It's true that this is the planning method required for all large projects. That's exactly the point. The implication of the original post and some of the follow-up comments has been that there is no planning at all in agile development. In that context, it was necessary to point out that agile methods don't excuse us from planning.
The assertion is made by people who have never actually used agile methods. I would encourage you to consider that when assessing their comments. -
RE: More on Extreme Programming
>If only we were all robots, eh?
Aren't we? Some do seem to react to things in the way they've been programmed.
>You can make a link by going into HTML mode, and writing the HTML yourself.
Thanks. Maybe I should actually look at the available options once in a while.
>I'd like to know, once and for all, and
in no more than 4 short- to medium-length sentences, what you think
agile really is. Give it to me short and simple. We can always work out
the details later.
Are you serious? The Agile Manifesto consists of a four-statement summary of the key concepts, and we (our whole industry) have been working out the details for the past five years. As for me, I think the most important statement in that manifesto is the first one. There's a lot of overlap across different processes and methodologies, especially those in the "lean" and "agile" camps, but I'd say that one point is the key differentiator.
At the risk of exceeding the sentence limit you impose, I think it's a good idea to recognize that some of the things we're talking about are at different levels of detail. An approach (e.g., adaptive vs predictive) is a a high level of abstraction; it's more a question of mindset than detailed practices. A project management process (e.g., Scrum or CMMI) frames a project from end to end and keeps track of progress. At the lowest level of detail, a methodology (e.g., XP) specifies particular software engineering practices that people are supposed to follow in their day-to-day work. To compare "agile" with "XP" is a synecdoche. -
RE: More on Extreme Programming
Whiskey,
It's a cute comment, and would be funnier if it held a grain of truth.
After all this time, a lot of people still think there's no planning
and no engineering rigor in XP or other agile methods. Oh, well.
I've seen many examples of teams who say they're using XP, when in fact
they're just making a half-assed stab at TDD or pair programming out of
context. Quite the opposite of casual or unplanned cowboy coding, XP
requires such a high level of professional discipline that it takes a
conscious effort to maintain the intensity day after day. The 12
practices complement each other in such a way that if you do it right
you'll get excellent results, but if you do it wrong you'll fail
spectacularly - probably worse than with traditional methods, which
have sort of a built-in safety net of administrative procedures.
At our company we have built a small but successful internal agile
practice. Initially we tried to adopt XP fully. We got it right on a
few small projects, but ultimately we came up with a hybrid methodology
that includes some XP practices but is a little less demanding on
developers. It isn't as effective as full-bore XP, but it's a lot more
accessible to the average developer. Reality, as it so often does,
intrudes rudely on a beautiful theory.
As far as agile planning is concerned, you might find this article by
an agile consultant interesting. She briefly goes over the five levels
of planning the agile approach requires in order to be successful. I
haven't yet figured out how to make a link work on this site, so I'll
just put the url in as text. (My bad.)
http://theagileblog.net/2006/04/gimme_five_the_five_levels_of_1.html
Of course, you will only be interested in that if you're open minded
about the agile approach. Those who are still at the level of dogma and
who enjoy snappy little quotes might prefer another blog entry, in
which the author convincingly destroys XP with unassailable logic, and
in the process proves that a solid, logical argument can be built from
an invalid premise.
http://weblog.burningbird.net/2006/04/13/technology-is-already-extreme
I hope you enjoy both pieces!
-
RE: Electronic voting conceptual question
If I vote electronically on your question, how can I be sure my vote is counted?
-
RE: Does Agile work for standard software development
ammoQ wrote,
>I cannot imagine a team running
through a full iteration cycle for just one of those cards, since it
takes hardly more than 10 lines of code to implement them (assuming the
methods for loading and saving the document are already implemented).
I can't imagine that, either. There's a lot more rigor involved than you seem to realize.
The statements on the card serve as a starting point for discussion. "Hardly more than a title" is okay. Remember that agile methods emphasize "individuals and interactions over processes and tools." The customer is present, as are team members having all the skillsets needed for the project. During the first half of the iteration planning meeting (IPM), the customer identifies the requirements he/she would like to be implemented next, in priority order. The team asks any questions they want to clarify the requirements. The team may recognize technical hurdles the customer's requirements present, and they can explain that to the customer. Collaboratively, they come up with some reasonable set of expectations for the iteration.
During the IPM the description of the requirement is going to be expanded considerably beyond the statements on the story card. One difference between agile methods and traditional methods is that this elaboration is not done for the purpose of producing a comprehensive requirements specification document, but only to help the team build the actual code. For that reason, whatever the team members write down during the IPM may not be retained beyond the end of the iteration. It's only interim documentation.
The second half of the IPM is the time when the team decomposes the stories into chunks of work, sometimes called "tasks" but sometimes the work is just broken up into additional stories. Technical dependencies are identified. For instance, if the methods for loading and saving the document are not already implemented, then that work is scoped out at this time.
One goal is to decompose the work into chunks that are roughly the same difficulty. A common rule of thumb is that a story (having been sized and estimated) should take between 4 and 16 ideal hours to complete. Some stories will only take a few minutes to implement. Others may take days. The work needs to be organized into chunks that are roughly the same size. A number of trivial stories might be collected into one, and a very large story might be decomposed into smaller stories using a skill from the good old days, "functional decomposition."
The reasons to break the work down into similar-sized chunks are (a) to make it easier for the customer to change priorities or substitute stories as needs change, and (b) to help with tracking progress. A popular tool for tracking progress is the burndown chart, a line graph showing time on the x axis and some unit of value on the y axis. The y axis could show story points, features delivered, or even the monetary value of the completed stories, depending on how progress is to be measured. If the stories were of wildly different sizes, the burndown chart could become meaningless. A team might deliver 45 tiny stories in one iteration and 1 giant story the next, and you wouldn't be able to tell what was going on by looking at the burndown chart.
All this activity is time-boxed. IPMs typically take 8 hours. The first half takes 4 hours, is led by the customer and supported by the team, and has specific goals as mentioned above. The second half takes 4 hours, is led by the team and supported by the customer, and has a different set of specific goals. All this estimation and analysis takes place quickly. The experience is very intense and interactive. It's been mentioned on the thread already that agile development requires highly skilled team members. This is one of the reasons why. Junior programmers lack the experience to be able to make reasonable estimates that quickly.
The resulting estimates are not set in
stone; they are a best guess at a point in time. That's one of the
reasons frequent and open communication among all stakeholders is so
important when you use this approach. When things change, everyone
needs to know why they are changing immediately so they can adapt to
the change in the most appropriate way. It's a very exciting and rewarding way to work, IMO. -
RE: Does Agile work for standard software development
Alex, re ground up vs top down...
Seems like most systems are approached from both directions at once, regardless of the formal methodology used on the project. Agile projects start out with a general high-level design that represents a top-down view. It is not elaborated as fully as it would be with traditional methods before beginning development, but it is still a top-down view. Similarly, in traditional projects, developers usually build a lot of components from the bottom up even though the design approach is top-down. They will often build the foundational layers of code first. The same thing happens on agile projects and for the same reason - nothing will run without that foundational layer of code.
When you look at the earned value chart from an agile project, you will typically see an S curve that shows relatively little business value is delivered early in the project, then a lot of value in the middle, then only a little value toward the end. The reason for the flat curve at the beginning of the project is that the team has to build a certain amount of foundational code and may have to do things like setting up servers and defining database schema and arranging for network security before they can implement any of the customer-requested functionality. Then the value curve rises sharply because of the agile principle to deliver features in the order prescribed by the customer, which usually means the features that represent the greatest value to the customer are delivered first. Finally, the team gets around to building the lower-value features that were farther down the customer's priority list.
This is a time when agile methods allow us to do something traditional methods can't, due to the way they are structured: We can terminate early with success. The customer may decide they have gained enough value and there is no need to build the remaining, low-priority features. I have had this happen sometimes on customer-facing projects.
It doesn't happen on internal, technical-type projects because the value of those projects is calculated differently. They are usually cost-justified on the basis of reducing operating costs rather than on the basis of increasing revenue. Technical projects are usually funded from an IT budget pool rather than directly by a business unit, too. Business units don't want to fund enterprise projects such as SOA implementation because they feel like they're funding someone else's ROI. That's another difference between types of projects that might influence our choice of methodology.
I mentioned the earned value chart - traditional projects usually don't track progress in that way, because they expect to deliver all the specified requirements at once; therefore, it doesn't matter in what order the features are built, and there is no need to pay attention to which features correspond to the most business value. That's okay for technical projects funded out of the IT budget pool. It's less okay for projects funded directly by business units, because they need to know the ROI.