Lesson: Pick one, two, or three up front
We also discovered that sometimes one week or three week iterations are better than two week iterations. We experimented with a three week iteration for the last iteration of the two month term. It made sense for one of the projects (to be released soon), but it definitely contributed to sloppiness and missing the deadline on another project. With more time it was easy to say “We’ll deal with that tomorrow” or “We can worry about that next week.” Turns out when you start saying that you’re often already in trouble. Without a looming deadline you can feel (you can feel the pressure two weeks a lot more than three weeks), scope creeps and things get pushed off. So we decided that next time around we’ll experiment with one week, two week, and three week iterations — but that call needs to be made up front. You can’t start with one week and turn it into two or three. A team will say “This is a one weeker” or “This is a two weeker” etc.
(Link: A New Way of Working: A Two-Month Recap – (37signals))
Uncategorized
management, programming
Development is a unique job with unique requirements. Two requirements that stand out are the need to work for stretches of time in complete isolation, concentrating intently on a problem, combined with the necessity of group collaboration. How, we asked, could we create a workspace that grants a developer access to both complete isolation, while allowing instant collaboration? We’d tried all manner of offices and desk arrangements in the past, then thought, why not build everyone their own house? On wheels.
(Link: Developer Town – Developer Town Blog – Why houses?)
Uncategorized
programming
His theory breaks job satisfaction into two factors:
* hygiene factors such as working conditions, quality of supervision, salary, safety, and company policies
* motivation factors such as achievement, recognition, responsibility, the work itself, personal growth, and advancement
(Link: Nine Things Developers Want More Than Money)
Uncategorized
management, programming
1. Be a developer
I can’t stress this one enough. Development isn’t something that can be appreciated, it has to be experienced. HTML and JavaScript don’t cut it, you have to go out and actually do what your programmers do. Write SQL statements, create classes, build an application. When you can follow along and contribute intelligently to all the technology discussions, developers will start to trust you that you understand them and what they have to deal with. And most importantly you can help them find solutions they may not see yet.
(Link: 12 Lessons Learned for Getting Better Results from Developers)
Uncategorized
management, programming
Automated recruitment test reduces the cost of screening of a programmer. Recruitment testing decreases the amount of interview work by up to 90% by requesting the candidate to write a snippet of a code in an online assessment tool. It also allows the recruiter to test employee in a natural working environment.
(Link: Codility.com – Automated tests of programming skills. Assessment of software developers.)
Uncategorized
hiring, programming
Switch the spec process from push to pull. Start with a one-page spec, no more. Then, let the team ask questions of the product manager whenever they need clarification. In exchange, the team agrees to show each piece of working code to the product manager for his approval. They’ll find points of disagreement much faster, and resolve them in realtime. Plus, the team will get better and better at interpreting the concise specs that only have to be written once. (Eventually, they may abolish specs altogether)
(Link: Lessons Learned: The product manager’s lament)
Uncategorized
management, programming
Feature flags and flippers mean we don’t have to do merges, and that all code (no matter how far it is from being released) is integrated as soon as it is committed. Deploys become smaller and more frequent; this leads to bugs that are easier to fix, since we can catch them earlier and the amount of changed code is minimized.
This style of development isn’t all rainbows and sunshine. We have to restrict it to the development team because occasionally things go horribly wrong; it’s easy to imagine code that’s in development going awry and corrupting all your data. Also, after launching a feature, we have to go back in the code base and remove the old version (maintaining separate versions of all features on Flickr would be a nightmare). But overall, we find it helps us develop new features faster and with fewer bugs.
(Link: Flickr Developer Blog » Flipping Out)
Uncategorized
branching, deployment, programming, scm, versioncontrol
In software, adding a six-lane automobile expressway to a railroad bridge is considered maintenance—and it would be particularly valuable if you could do it without stopping the train traffic.
(Link: You Don’t Know Jack About Software Maintenance)
Uncategorized
management, programming
Ruby metaprogramming, at its core, is actually quite simple.
It comes down to the fact that all Ruby code is executed code–there is no separate compile or runtime phase. In Ruby, every line of code is executed against a particular self. Consider the following five snippets:
(Link: Metaprogramming in Ruby: It’s All About the Self « Katz Got Your Tongue?)
Uncategorized
metaprogramming, programming, ruby
There are many traits a good developer has. Focus. Sense of Quality. Interest in what he does. Knowledge of programming languages and skills in software development. An opinion. Team player.
But the things I most value are professionalism and getting things done.
(Link: As a Manager: What I value in developers – Code Monkeyism)
Uncategorized
management, programming
Configuration Management
1. Do you know what a baseline is in configuration management? How do you freeze an important moment in a project?
2. Which items do you normally place under version control?
3. How can you make sure that team members know who changed what in a software project?
4. Do you know the differences between tags and branches? When do you use which?
5. How would you manage changes to technical documentation, like the architecture of a product?
6. Which tools do you need to manage the state of all digital information in a project? Which tools do you like best?
7. How do you deal with changes that a customer wants in a released product?
8. Are there differences in managing versions and releases?
9. What is the difference between managing changes in text files vs. managing changes in binary files?
10. How would you treat simultaneous development of multiple RfC’s or increments and maintenance issues?
(Link: 100 Interview Questions for Software Developers – NOOP.NL)
Uncategorized
interview, programming
Client Examples
1. It costs an average of 20 minutes lost productivity every time the customer or manager phones a developer to find out how the project’s coming, in addition to the time spent on the phone
2. 4 hours are lost for each meeting that takes place between 11am and 3pm, in addition to the time spent in the meeting
3. About a week of development time is lost whenever someone from marketing makes a fuss about adding “a trivial feature that’ll only take 1 hour” so he can close a sale
4. Most clients will not provide the most important requirement until a project is two-thirds developed. They will not even realize it was a requirement until they begin to see proofs
5. Any given proof has only a 20% chance of being reviewed by the client at the time it’s submitted, and a 90% chance that the client will request changes to the proof after 1 week has already elapsed
(Link: N Examples of Why Time Estimates are Always Wrong (Software Engineering Tips))
Uncategorized
development, programming, tweet
Most comparisions take 5 to 10-year-old brownfield, legacy Java projects with hundreds of developers – many of them average – and compare them with 2-year-old Rails projects, where the initial developers – most of them excellent – are still on board. For a real comparison one would need to compare state of the art frameworks, Webbeans/Wicket, Stripes/JPA with rapid development frameworks like Rails and Django. I’ll spare this comparison perhaps for another post in the future, but would be happy if someone does a decent comparison. I consider this question open.
(Link: Is Java dead? – Code Monkeyism)
Uncategorized
java, language, programming, tweet
Software teams are always asked to do more with less. If you estimate a product should take three months, you’re asked to deliver in two. If you tell management you need ten developers, you’re given eight. How do we ensure our teams are operating at top efficiency? How can we make sure that we’re doing all we can with what we’ve got? Here are some essential truths about software teams and the software development lifecycle that none of us can afford to ignore.
(Link: Software Team Optimization: The Art of the Ongoing Tune Up)
Uncategorized
agile, management, programming
Tersus is a Visual Programming Platform for creating rich web applications.
Simply draw flow diagrams and Tersus will bring your application to life.
Tersus is open source.
(Link: Tersus: Visual Programming Platform for creating rich web applications.)
Uncategorized
ide, programming
