Slashdot Mirror

Fork Shmork. If they were forking it, they should have have been more forking forthcoming. Instead, they make it seem like they're working with the oss community on projects - they release all these changes and everyone think's it's great, but all the changes are useless for anything but WebCore.

Well, first, besides the newfangled ACiD test smiley face, Konqueror is a very good rendering engine. It renders most pages as good as Firefox, somtimes a little nicer. The font rendering in Konqueror tends to look better on my systems then they do in Firefox/Mozilla.

So, we should just throw in our hats and all write Microsoft-caliber software? We should do away with pride in our work, in getting it done right, in effecient executables because you think it's out-dated?

WebCore is not beautiful, but the KHTML team makes it sound like the software wasn't released, but instead clawed a bloody trail free from its unwilling host body and now assails innocent teens who are making out in the Old Lake House. It is not that bad at all. Certainly, it's above the standards of most software released today.

I think the whole idea that you need to ship, ship, SHIP software is showing it's age. I salute the KHTML team for wanting the code to be clean and effecient and retaining the things that make it good. Small footprint, efficient code.

I guess the whole "improvement" is subjective. They might have improved the way the thing renders some things but at what cost? According to the KHTML folks, the apple improvements came at too high of a cost. Messy patches and OSX specific code.

I didn't have unresonable expectations. I expected Apple to behave like decent netcitizens. They should have made their intentions clear from the start (a full fork, see ya KHTML.) If they really intended to work with the KHTML team they could have easily made it work. Other companies do.

Check out these points from "Principles of the Agile Manifesto":

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.

The between-the-lines point here is that getting working and not-awful code now is the secret to success in the long term. Dozens of projects have proven this over and over. UNIX is probably one of the most famous examples, as suggested in the famous "Worse Is Better" essay.

Polishing code until it's perfect without new feature development is an excellent way to get outdated.

So basically, KDE should read this

So basically, KDE should read this.

The ideal design document is the one you didn't have to write because you were too busy delivering well tested, working software to your customer. This is a lot better than the 300 page design document (which the customer in truth doesn't give a damn about) that you deliver only to have the requirements change 20 times, which are still incomplete, which lead to your project cancelation. I look at it this way: typical software development lifecycle assumes not only that you can know everything up front, but that you make the right decisions with the information. Dispite more than 30 years now (see The Mythical Man Month, F.P. Brooks) of repeated demonstrations that this doesn't work, projects are still too often structured around this flawed concept. A lot of Agile approaches discard this ritual or at least put a reasonable devaluation on it.

Take a look at Agile Manifesto for more info.

The Globe and Mail reports that 'A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.

The answer to this problem is change, and isn't change always the answer?

Consider if you will for a brief moment the vast difference between the average executive and the average programmer. Programmers are generally broad-picture thinkers who solve largely complicated problems that regular folks can't possibly wrap their heads around. The executive runs on a schedule and uses reports and correspondance to understand what is going on, because business folks have to judge their employees and projects.

These two groups are forced to work together, and we expect good results? We need someone to interpret between these two groups! The HR department can't regularly serve in the interpretive capacity, but perhaps they should.

Managers generally don't want to give the programmers the whole picture, because management often believes that they are superior in rank to programmers, placing the programmers on a need-to-know-basis, only. Huge mistake.

What programmers and managers need to do is realisticly approach their solutions together. They need to be honest with each other. They need to share each other's thoughts and feelings about the subject matter. It's not happening today.

The programmers need to come to the table and care about their customers a little more. The managers need to come to the table and care about their programmers a little more. The customers need to be more specific and realistic about how far their dollar can go. Then deadlines will be met and promises kept and successful solutions provided to customers.

I encourage a no-holds-barred approach to project management. The superior product is developed using the Agile method.

I suspect there is some ridiculous "methodology" called "Agile" that those silly programmers use to try and make their code less sucky, and the poster wonders if it could be usefully applied to SA work.

Well, unless it involves us learning how to get a job where we can put any misconfigured piece of DHCP request answering shit on someones production network, then go away to play pool on the table that was installed "because we're creative and have special needs", then I don't really want to know...

But, let's be fair and take a look at what agile is... (from http://agilemanifesto.org/)

Processes are bad.
"Hey, my account won't let me sign in!"
"Yeah man, that new account generation proccess that ensures you get access to the dozen departmental systems that people designed themselves because they know better, that was just too fascist for me man!"

Deliver stuff early when it partially works - yes, we SAs invented that, it's called kludging.

Talking to people in your team is a good way of communicating - yes, also we've heard there's this thing called fire that you can use to heat things up.

Working software is the primary measure of progress - you don't say! Really? I also heard there's this thing called fire that you can use to make cold things hotter.

You should try to make your software well designed and technially excellent - that's where my Perl scripts have been going wrong! I've been trying to make them shit all this time! D'oh!

Motivated people make better programmers - cattle prods are motivating, aren't they?

Do I sound bitter? Well, today I had to spend an hour of my life (that I won't get back again) teaching a perfecty intelligent person how to jump through the stupid hoops needed to make a piece of shoddy software designed by an intellectually challenged monkey perform a simple task for them. Yeah, making all twenty icons look the same, that was good idea. Maximise should show you more of the current document? No way man, it's just a conspiracy - don't let those Micro$oft bastards force you to comply to interface standards.

Okay, I think needle-head means this. Looks to me like "Agile Methods" are equivalent to "endless point releases and a never-ending project timeline that sucks up client cash and developer time"

I'm not calling Scrum bizzare. Scrum seems like a good way to develop a piece of software where the requirements churn is very high. I have a hard time thinking of such a system off the top of my head. It might be an acceptable way to develop a low-churn system where you want your time-to-market to be next to zero, provided the cost of a failure is very low, and redeployment costs are minimal, and you don't mind burning some cash down the road to get to market first. A web-based email system, for example, might be a good candidate for scrum. I'd also think that you would need a fairly small team size for scrum to work properly, although I don't have data to back that up.

A mission critical system, though, where the cost of failure is high (say, death), is not really a good candidate for Scrum. If you worked at Boeing and found "777 left wing" in your process backlog, you'd probably want to seek employment elsewhere.

With any mission critical system, you need a very clear understanding of the requirements before you start design - otherwise there is a high probability that your design will fail to meet one of those requirements, and therefore the system will likely fail. The whole point of scrum is that you basically make up features (and, therefore, requirements) as you go along, and hack them in. Your product backlog is basically just a list of features you want but haven't had time to hack at yet.

The requirements of a mission critical system do change, as new features do get added (communications gear is a good example of a critical system with low-medium requirement churn), but scrum is still, IMO, inappropriate, as the rate of change is generally far too low.

Scrum also seems to lead to a lot of rework. If you find a requirement buried in your product backlog which you hadn't previously considered carefully, you may find you have to rewrite a substantial ammount of design to add that requirement. Again, in a system where your requirement churn is high, this is perhaps unavoidable, but in most systems (especially mission critical systems) the majority of your requirements are known ahead of time, so all that rework just becomes waste. The waterfall model would serve you better.

Finally, Scrum has a few pitfalls. Since your product backlog is generally full of features, it's easy to end up doing things like assigning features to designers instead of subsystems. The "sprint" mentality also seems to make it easy to shirk the responsability of producing correct documenation. You can do (or fail to do) these things with the waterfall method too, of course, it just seems like Scrum almost promotes them.

As for "There's nothing inherent in any agile methodology that precludes CMMI compliance," I'll point you to the Agile Manifesto. Let's just look at those first two points here;

1) "Individuals and interactions over process and tools"

How does this relate to CMM?

"Success in Level 1 organizations depends on the competence and heroics of the people in the organization and cannot be repeated unless the same competent individuals are assigned to the next project. Thus, at Level 1, capability is a characteristic of the individuals, not of the organization." - http://www.dfas.mil/technology/pal/cmm/lvl1desc.ht m

So the first point of the Agile Manifesto seems to scream out CMM level 1.

2) "Working software over comprehensive documentation"

Even if you had excellent quality software with poor documentation, the software would be difficult to change and maintain, unless you assign tasks to people who are intimately familiar with the existing code base (Sound like CMM 1 again?). If a person moves to a new project, there is a siginifigant learning curve. This is compounded by the unfortunate fact that, at my company, developers are assigned features, rather than subsystems. A new developer must t

NOTE: blatant self promotion.

I maintain a list of books and other resources for all sorts of people who work in the software development field including of course, programmers, managers, executives, testers, etc.

Software Resources

The list is heavily weighted towards Agile software development.

Python/Zope will allow me to interface with multiple RDBMSs easily. The key is to use the tool that best fits the job. One size does not fit all. There is room for Java solutions; however, I have seen no pressing need to change from the perl/python I am using now for those server-side solutions.

Enterprise application development involves much more than just hacking together app in a a few hours...

My job is to make my customers (be they internal or external) happy. If that means hacking together something in a few hours - then I am going to do it. I am going to use every tool in my arsenal to deliver the solution when (before if possible) they need it - and then factor out any bottlenecks not anticipated (something you will still have to do regardless of what environment you use).

This goes to the core of the difference between classic 'waterfall' development techniques, and more progressive agile software development. The focus in classic design is to have everything defined up front and is reflected in the tools chosen for particular jobs. In reality, unless the application is trivial, this is not attainable in practice. Given that - I can't see any convincing argument that will bring me to embrace Java (on the server or client side).

I liken the difference between classic development methodology and agile development as the difference between a boxer and a streetfighter. The boxer is constrained by the rules, whereas a streetfighter will hit you with a brick if that is the most effective way to bring you down. Results are the touchstones of successful software development projects. I have seen enough projects go massively over budget and fail to deliver the promised functionality to know that classic 'authorities' do not trump results.

The declaration stinks of pointy haired people sitting in afternoon long meetings

Would you rather have fat-assed old farts in standing around a white board?

Windows has a _much_ more powerful API - ProtonMotiveForce

I can do more under Unix (up to and including rewriting the kernel) than you can do under Windows. You are constrained. Microsoft forces you to program a certain way - there are no alternatives. If that is your definition of 'more powerful', then I think you have something to learn about 'power' where a computer is concerned.

Windows has better threading support, a better asynchronous programming model, and a much more powerful network API

Threads have been shown to be more difficult to program, and thus more likely to have bugs than using interprocess communication. Unix's norm is to build many small tools that communicate in standard ways (piping standard output of one application to standard input of another, or via sockets across the network) and lash them up to get work done in ways the original developer may not have imagined. Our goal is usable applications for our users - not buggy code that makes the users pull out their hair.

Asynchronous progamming model; not something I have found in my research or experience. Perhaps that is another name for ?...? Is that really desireable? I ascribe to the spiral development model myself (or any of the variations attributable to agile software development - aka extreme programming). It works; you might try it sometime.

As for network APIs, how can you get more powerful than Expect? You simply instantiate an application (such as telnet, ftp, etc.) and use the reference returned to filter the resultant data stream from the remote application - and have your application respond as appropriate. I know of no Windows API that is as easy to use as that.

Here is what you should be doing if you develop under *nix:

1. Ask yourself if the application would be better served as a web based system. If so, use Zope, java or any number of other tools available for the task. This is the ultimate in portability because anyone with a browser will be able to use your application.

2. If your application absolutely has to run on the client machine, then use a 4GL as core language, such as Python, Perl, Java. Consider C as glue, and only use it sparingly. I would suggest standardizing on the TK gui tool kit - which is available for most languages including Python and Perl.

3. If your application has highspeed graphics or a realtime monitoring utility, then use accepted libraries, such as OpenGL etc, and program using the fastest language - C.

4. Forget all of that 'powerful API' BS the Microserfs keep yelling at you. Remember: the "highest priority is to satisfy the customer through early and continuous delivery of valuable software" - Agile Manifesto. Keeping your customers waiting because you spent fifteen days finding a bug in a Windows API is unacceptable. Similarly, wasting time trying to build something from scratch that you could have delivered in less time using existing standards, frameworks and 4GL languages is also unforgivable. Everything else is fluff.

Finally, you say that Microsoft has 'courted the developers' - I believe they have lead you down a narrow path by your nose. They have certainly not 'courted' me, as my standards for supplying my user base with working software is higher than any holy war.

2. Testing, testing, and testing -- by the developers.

probably not a good idea. while I would get them to test their archictecture, algorythms and performance I would leave any real testting to a QA team (hey thats if you really have one).

3. QA, QA and QA -- by someone other than the developers!

very true. *monkey-testing* for input screens, navigation and design. Load and stress-testing may reduce any performance bugs. But the one that may bite is the RDBMS for database intensive sites where developers have made changes to stored procecures on the db. Is the SQL code in CVS? Can we roll back the db on the live site if needed? Opps we make changes to the live DB :( This is one are where having *restrictive* per-seat db licences bite.

4. Managers must know the test/ QA process should never by bypassed -- this unfortunately is probably the hardest point. :-(

the phb problem. no amount of testing, development rigour will avoid the *monday morning* crash with 100's hasty ill-defined of cvs commits in the weeks previous *mandatated* with/without poorly defined specifications. Of course you have to balance this with a business being able to adapt quickly. But I remember one marketing clown thinking *development was easy* and could be learnt in 15 minutes.

There are no *silver bullets*.

Working with fragile web based systems almost warrants XP unit type testing approach. Other agile development approachs might be useful.

unlike eXtreme Programming, which is mainly about coding.

Scrum is all about managing the project, and in a way which matches the reality I perceive better than "traditional" models.

I've read the book in question, and I believe in Agile methods. One of the comments above says "methodologies are nowhere near as important as people" - check out the Agile Manifesto; line 1 says "we value individuals and interactions over processes and tools". Ken Schwaber (and Jeff Sutherland, who posted a reply here) are co-signatories.

The big problem I have found with Agile methods is that often the senior management team is unwilling to relinquish the impression of control over their projects. They insist on knowing everything up front - time, scope, budget - and even if they understand the empirical nature of software projects, that sense of control is very hard to give up.

I have found many of the "Top-down" implementations of Agile processes to be buzzword driven - the last thing you need to do Scrum is a new VP; the Scrum is intended to make the VP redundant ! I'm not surprised many people have had bad experiences with XP - the 12 practices are finely balanced, and distorting that balance (e.g. by over-emphasizing "the simplest thing that could possibly work") is a great way to ruin a project. Of course, I'm inclined to believe those organisations will struggle with any methodology; one thing Agile methodologies seem to do is draw out organisational weaknesses.

I'm working on a project right now where we have a very agressive schedule; we are pretty sure we can code the thing, but because our average corporate decision takes longer to reach than the project's timeline, we're hitting some rough spells. The cause is the decision making process; the effect is an unhappy project. In a "traditional" project, with analysts and project managers etc. and a sizeable up-front analysis phase, our corporate weakness would be less obvious; because we're saying "decide today, we'll have working code by the end of the week", our inability to decide is highlighted.

I'd recommend Ken's book; it's worth reading, and even if you don't agree with all he has to say, you might learn something.

Requirements are the Achilles heel of XP.

I work in a game studio where our last project had 6 months of pre-production time. We generated reams of technical design documents. The intention was good, but they were never maintained or even referenced after their initial creation. We just said "documentation is necessary" and it needed to be done. In production, the team wasn't on the same page. Every programmer had a task list they just milled through. The assumption was the initial requirements won't change. The result was ugly. The product was subpar and a couple months late. Everyone was miserable. It sucked.

I'm currently leading a new project here. We're 6 months into production and every milestone has been delivered ON TIME and accepted by our customer. The team is focussed on the current milestone, there isn't a lot of process to get in the way. The best part is, writing code is fun again. We don't have goals we can't accomplish. And we fully expect the product requirements to change during production.

I could get into specifics about our process. But I don't think it would be that helpful. I think specific methodologies like XP are guidelines to get you started. From there, you really should re-evaluate your process frequently (a fundamental excercise to be "Agile") and make changes as necessary. Kind of like optimizing your code.

The following links gave me all the information I needed to devise an initial process plan (which included TDD). But once it was put into practice, it naturally evolved into the process we have now (which doesn't include TDD)...

The New Methodology by Martin Fowler

The Agile Manifesto

Agile Software Development Ecosystems by Jim Highsmith

I also suggest reading the chapters on "thematic milestones" in Writing Solid Code.

We don't need any more of this - we all just need to learn how to be practical craftsmen that get *work* done.

Sure.

No amount of process will ever make up for proper training, proper documentation, proper version control, and proper testing. Ever.

A process is supposed to precicely about a framework for accomplishing those things. Sadly, it doesn't tell you how to do the work. That requires experience.

If you have good people, set them free.

Depends what you mean by this. Do you mean -- everyone is autonomous, let's hope for emergent organization? Or do you mean -- let's come to a consensus of the MINIMAL required ceremony to get our jobs done in the most effective way possible? The former is possible with a very small team of experts. The latter is possible with a (more likely) team of mixed-expertise(high/medium/low).

What I'm trying to say is that process & methodology doesn't have to be about getting poorly [trained, motivated, disciplined] people to develop great software. It just happens that many poor managers (which are in much larger supply than poor software developers) tend to apply it that way.

Agile processes are precicely supposed to be about letting good people get their job done, without stepping on each other! That's the whole idea behind XP and its ilk.

Object oriented technology, patterns, etc. are all techniques for experienced programmers to create more maintainable and expressive programs by elevating the level of discourse. They can be misused. They don't substitute for experience. But there is value there.

By suggesting that "we don't need none of this extra stuff", you are right -- yet there still is a place for that "extra stuff".

It's kind of like Maslow's hierarchy of needs. At the base levels, you need good [disciplined, competent, motivated, intelligent, trained] people, good team dynamics, good technical management, support from general management.

This is the kind of stuff that the Agile Alliance believes in. People over processes, collaboration over negotation.

At the upper levels of the hierarchy of needs are things like tools, processes, and higher-level programming constructs. They do add a lot of value to software development, but are not first order success-factors.

Exactly, this is what the agile methodologies do. See the Agile Manifesto.

The founders of XP are part of the agile alliance.

A quick warning... I consider myself a relative newborn in the world of software development. I present these opinions under the consideration that my opinions can change at any moment. =]

A lot of the dire predictions of software atrophy and such are a result of applying the wrong methodology to a project. Yes there are uses for Software engineering, but I think this approach is overkill for even large scale projects. Check out Software Craftsmanship: The New Imperative for a different perspective. A perspective I think is in need of serious consideration. The gist is returning to the days of master craftsman and apprenticeships. This focuses a bit more on the learning aspect than actual development methodologies, but you can always go to The Pragmatic Programmer to fill in that gap.

"As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress."

This is where "refactoring" (see Fowler's Refactoring) really shines. I find it difficult to believe that refining the software base is not progress. An initial revision where the code functions by its contract (if your into designing by contract), then you refactor the body of the function/method for speed / elegance. Then you can run your unit tests on the function / method to test that the refactoring session did not break any of the design contracts (whew).

I think they may be trying to restate the broken window theory (see Pragmatic Programmer), were a broken window (or bug) in a building (or system) leads to delapidation elsewhere in the building (or system).

And then there are the agile methods, including XP. I think these answer a lot of the limitations and issues with Software Engineering practices. Interacting with clients (having a client there during each iteration) gives you the benefit of almost real-time feedback so that you can update your user stories on the fly, etc.

Without rambling on any farther, my point is not too spend too much time looking for a specific unified theory. Read up about all the ideas, methods, and theories. Take the best parts from each, then crank the knob all the way up (if I may borrow that from XP =] ). Don't let anyone tell you there is a science to software development that is easy to reproduce, and that you are just a link in the overall chain. You practice and perform a craft. Enjoy it!