Making something a BIG RED TOP TOP BIG HIGHEST #1 PRIORITY changes nothing but text styling.
Story card hell is when you have 300 story cards and you have to keep track of them all.
If your product backlog contains more than 50 Stories, there probably are inconsistencies due to lack of comprehensiveness.
A stuffed backlog is a stale backlog.
Often traditional requirements gathering bloat up Agile product backlogs so that they cannot be prioritized anymore.
Meetings are toxic: They usually convey an abysmally small amount of information per minute.
What exactly is wrong with meetings and managers (or M&Ms, as we call them)? Well there is nothing intrinsically wrong with them. What's wrong is how often they're applied in office situations.
If you are in a room with five people for an hour, it's a five-hour meeting.
Meetings procreate: One meeting leads to another meeting leads to another...
By rationing in-person meetings, their stature is elevated to that of a rare treat.
We lead people not machines, we embrace spending more time with our team than in meetings.
Last but not least: Never forget to run the awesome Meeting-Ticker…
Can you spot the differences:
I'm convinced there is a need to replace JavaScript.
JavaScript was that component of the Web that everybody underestimated.
JavaScript is fast becoming a serious contender to Ruby and JVM languages.
This is probably the worst thing any server-side framework can do: be written in JavaScript.
JavaScript is now established as a powerful, mainstream language that can be used in a variety environments both on client and server sides.
A very large group of developers still thinks of JavaScript as a joke.
JavaScript used to be the thing that we tolerated… Now it became the technology leader.
JavaScript in the browser is the single largest development platform.
JavaScript is a bubble. What is actually awesome about JavaScript has nothing to do with JavaScript.
Somewhere in the history of building web applications on the JVM, adding layers somehow became part of the solution without being seen as a problem.
Complexity is an expensive luxury… powerful solutions do not have to be complex!
You can only build so much on top of something else, before you have to wipe the slate clean and start over.
The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved. There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one.
People pile layers on top of layers, abstractions on top of abstractions, complications on top of complications, crap on top of patches, and patches on top of crap until everything collapses onto itself and the singularity appears.
OOP programs built as towering hierarchies of classes are like perfect crystals, to be admired by architects everywhere but loathed by the programmers responsible for maintaining them.
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Software teams have to move away from the idea that bugs are a useful way to measure quality.
Software does not have enough self awareness to be afraid of bugs. That's why it works as well as it does.
Testing shows the presence, not the absence of bugs.
Bugs are like over-parented kids. They get a lot of attention. They might be born in the relative quiet of a developer's IDE, but the moment they are exposed to the rest of the world, they live their lives amidst a great deal of fanfare.
Maybe there’s no such thing as a bug. Maybe there are just things that work well and things that don’t work well.
Unfortunately, in the celebration of testing artifacts (such as counting the number of bugs) we forget about the software. All testing artifacts have value to the extent that they impact the source code and therefore the product.
Comprehensive statistics of past bugs are no more useful for software quality than financial accounts of a chophouse are useful for a steak sandwich.
Nothing makes a system more flexible than a comprehensive suite of tests! Far above good architecture and good design!
We have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We're more of a testing, a quality software organization than we're a software organization
TDD is a discipline for programmers like double-entry bookkeeping is for accountants or sterile procedure is for surgeons..
Tests should be made a first-class citizen and treated like any other feature.
TDD, BDD and other high-ceremony techniques are not recommended for startups! Code is not important in the beginning!
I see TDD as a valuable and important development technique, but there are contexts in which it shines and others in which it is a hindrance.
Insisting on unit tests won't make those unit tests valuable.
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.
If I don’t typically make a kind of mistake, I don’t test for it.
Testing is overrated!
A survey of all the studies on TDD has shown that the better the study done, the weaker the signals to its benefit.
Thinking you can improve quality by doing more testing is like thinking you can loose weight by weighing you more. […] If you want to improve your software, don't test more; develop better.
You cannot inspect quality into a product. The quality is there or it isn't by the time it's inspected.
Much of the essence of building a program is in fact the debugging of the specification.
The single most important thing on a project is picking the right people. If you have good people then it doesn't matter if you are using Scrum or not, it will turn out well anyway.
We were used to getting shit done … then they told us about Agile.
There are no agile projects. Nor were there ever any waterfall projects. What we had were just a bunch of guys trying to get a bunch of stuff done.
We must destroy these methodologies that get in the way of programming.
These statements make even less sense. They are just babble, and they’re not about your trade in any conceivable way.
I don't read agile books. They are a waste of time!
Agile books out there are just people telling stories about stuff. Stories are great -- love to hear them. But I can't trust the authors of most of these books to tell honest stories and learn honest lessons from them. Instead they have a theme.
The problem is, real life doesn't have a theme.
I used to be an agile consultant, but I am alright now.
Abstracting SQL often isn't a good idea from my experience.
Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity. [...] As professional programmers, we should be more sceptical of generic frameworks like hibernate.
There are easier ways to do it, rather than hitting your domain model over the head with NHibernate.
There is no measurement for technical dept. But the closest measurement is lines of code.
It is all very complicated but not magical!
Their "one-click-deploy" involved a telephone call, copy-paste sql-scripts and chanting & praying.
Software development is about creating something specific not something generic.
(Else you can send the customer a virtual machine, that´s generic.)
Take your last shipping project: Probably you could power-type all the code in one day … How do we spend our time?
About productivity: How good are you in thinking while typing?
If you have git, you have source control - if you have TFS, you have my condolences.
A very large group of developers still thinks of JavaScript as a joke.
JavaScript is Assembly Language for the Web.
JavaScript is the ugly duckling among programming languages. It takes time to embrace it and discover its beauty.
Javascript is fast becoming a serious contender to Ruby and JVM languages.
After almost a decade of the ruby community being the web innovation lead, it really looks like the javascript community is taking over.
Events such as the Rails Rumble have shown that it’s possible to finish software projects in two days that might take a corporate development team weeks or months in a normal project scenario.
Scott: What is the penetration of Node.js into the "enterprise"?
Tim: It depends on what you mean by "enterprise"?
Scott: Large, slow moving corporations.
The corporate environments are awful!
In corporate environments the product don't have to be good. Sometimes they don't even have to exist ... if you are a thoughtful developer, you are in the wrong place!
Fear leads to Risk,
Risk leads to Process,
Process leads to Hate
... and suffering and Gant-Charts.
You and your internal development team of architects are not going to build the next great framework. You’re not going to build a good one. You’re not even going to build an acceptable one.
True code reuse between projects in the OO world is mostly a pipe dream. That's why so many good OO guys end up being toolsmiths and writing frameworks -- out of a desperate desire to create true reusable pieces of code for common problems.
Reusable code is overrated a majority of the time. The focus should be on creating well designed software that is easily maintainable. Much more software can be built in a shorter time frame this way.
If there is one thing more frightening than mapping your way through a maze of twisty little libraries, it’s getting mired in the framework swamp.
Responsibility trap number one: Building a platform to make other (lesser) programmers more productive.
I can't read the article, the term "framework team" makes me shivering inside...
I love my work. Yet put me on a team with unclear goals, little collective responsibility, arguing, and infighting, and I'll wake up dreading going into work.
On the morning of his two year anniversary at the cubicle company, Ashton was driving to work when he realized something.Not one line of code that he had written had ever run.
Not one thing he had done in two years of work made any impact on the world.
In corporate environments the product don't have to be good. Sometimes they don't even have to exist ... if you are a thoughtful developer, you are in the wrong place!
In reality I have almost never met a passionate developer, that is really happy with his job.
The productivity difference between a happy developer and a disgruntled developer is enormous, and constantly underestimated.
Domain Driven Design is impossible with a classic three layer architecture where DTOs are being shared across layers.
If everyone agrees that it's obviously correct:...then you probably don´t have much of a domain!
- that the system has layers
- the one at the top is a website
- the one at the bottom is a database
Note that adding an ORM layer does not magically create a domain!
Scrum is easy, as easy as explaining push-ups... the challenge is the practice!
- rhundhausen,
proscrumdev brussels
I don't read agile books. They are a waste of time!
Agile books out there are just people telling stories about stuff. Stories are great -- love to hear them. But I can't trust the authors of most of these books to tell honest stories and learn honest lessons from them. Instead they have a theme.
The problem is, real life doesn't have a theme.
Agile development's primary tenants is to value people and interactions over processes and tools.
The principle sponsors of the Agile 2010 conference are "Agile" tool vendors.
Somehow, we've walked in a circle - yet again.
- Scott Bellware, User Stories are Temporary
We value code that is easy to maintain over code that is easy to write.
- Growing Object
Oriented Software
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
- Tony Hoare
The reason why business people use the word 'risk' is because they don't want to use the word 'fear'.
- Dan North, Keynote Oredev
Corporate Ping-Pong [...] it is driven by the wrong believe that working in batches and specialized silos makes us more efficient. 100% workload equals to 100% productivity. This is plainly wrong.
Working weekends to save a project is like torturing people to save a country. As soon as you do it, there's so much less worth saving.
If you build software from diagrams, it will likely follow good diagramming principles, but rarely follows good software principles.
Nothing makes a software system more flexible than a suite of tests. By an order of magnitude more than good architecture and design.
Learning from mistakes is overrated!
If we could only learn the right lessons from the successes of the past, we would not need to learn from the failures.
Code that runs on first write is an idea from the past that we should forget!
