Yourdon's top ten software engineering ideas

While I'm busy working in SCEA part 2, I wanted to share this ideas from Yourdon.
He has a mindmap presentation about the top ten software engineering ideas (you can download the pdf here).
What he talks about?
1 - You can't control what you can't measure
2 - Peopleware
3 - Incrementalism
4 - Iteration
5 - Repair costs increase
6 - Tradeoffs are non-linear
7 - Reuse is important
8 - Risk management provides insights
8 - Consistency trumps brillance + death march
10 - Don't reinvent the wheel

Lots to comment on each one (he shows Brooks's "The Mythical Man-Month" and DeMarco's "Peopleware", I must agree!).

Waterfall, RUP, XP... and one process to bring them all, and in the darkness bind them

What happens if you have a big project to execute and your organization mandates Waterfall? Of course, you can try to follow the mandated process, and hope everything goes fine (bad news: chances are not).

As a rule, you must ALWAYS adopt/adapt the process to fit your project (and not the other way around)

A big project will be less risky using RUP, but if you can't convince the outside groups (typically management, QA, overzealous SPEG/SPI group, maybe the customers too) to use it, you can use RUP and make it look like a waterfall from the outside (but ONLY form the outside). BTW you should try to convince those groups that waterfall only looks good on paper and modern processes can yield better results, but it takes time, and probably you need to start right now with the project. How do you map RUP and Waterfall? Don't do the classic mistake of Inception=Requirements, Elaboration=Design, Construction=Coding & Unite testing, etc... you will be in trouble when at the end of Inception, the outside groups will ask for the complete requirements for review!

The trick here is map the end of Elaboration to the end Requirements phase, so you can collect all the requirements but also implement the critical ones. You can map the end of the Design phase to somewhere in the middle of Construction (or at the end if you can get away with it). When you're done with Construction, you can release your code to the outside QA team to do whatever they want. Probably is a good idea to have customer involvement early so he can try the system and provide valuable feedback (that's the whole idea!).

You will end with an oddly shaped (in time/effort) “Waterfall-looking” schedule but still all the advantages of an architecture centric iterative incremental methodology like RUP. And if you can't live without doing XP and will complain if you can't do it, you can safely do XP inside each RUP iteration...

BTW, by no means TRANSITION=TESTING!!!!

What's your project score?

The Standish group's CHAOS report has a table of success factors:

Success Criteria	Points
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

The study is not new, but still is valid. This are the critical factors for a project success.
Mapping it to your current project, will let you focus on the areas that will improve your chances...
What is your current project score?

Software Engineering Radio

I really like this site. Software engineering podcasts in english from a german team of experienced software developers and architects. I really enjoy (almost) all of the episodes, some refreshed concepts (like architecture) and others gave me an idea of new topics (I'm fascinated with MDSD/DSL stuff, but still I couldn't try it). Some of the topics covered are Architecture, Patterns, Model Driven Software development, Agile process, SOA, Dynamic languages, etc (and very good interviews too).

The podcasts are intended as a reference resource, not technology specific or a news podcast.

My only complaint is that I have my MP3 player totally full because of their podcasts (guess I should get a bigger one) :-D

Bottom line: totally recommended, don't miss it... go now!

Sun Certified Enterprise Architect part 1 completed!

Good news! I just passed the first part of SCEA with a score of 89%.
Now comes the assignment part, it should be less stressful as there is no time limit and involves arhitecting a solution for a small system and document it in UML diagrams (that’s what I’m supposed to do for a living! :-) )
I must say it didn’t feel very difficult. First I bought Mark Cade’s “Sun Certified Enterprise Architect for J2EE Technology Study Guide” is a little bit short, but is a great overview of the topics and expectations of the exam. Is a truly study guide. I got good notes also from scea yahoogroups list. The mailing list is almost useless, but the files section has good resources.
www.moelholm.com has the best (free) exam simulator, if you pass the mock tests, surely you’ll pass the exam. www.leocrawford.org.uk has a very good review of the important stuff . I read it the day before the test. If you want more links, comments, details, let me know, I'll be happy to share them...
Now, I want to start the part 2 ASAP :-)

(UPDATE 05/14/2007: More links)
Java certification success, Part 4: SCEA
Good (although the stateful session bean lifecycle diagram is incorrect), can be a study guide similar to Cade's book but even shorter. You need to register to download it
Pete Morgan's Sun Certified Enterprise Architect Part 1 Notes
Nice notes, once you learned the topics, this will help you to keep them on your mind
CertMag on the Web Programming Success: The SCEA Certification
A guide to the certification and useful links, some of them old though

And of course, there's plenty of discussion in Javaranch's saloon, like this notes.

(UPDATE 05/17/2007: More links)
I found also this collection of links at Ideartis

Caffeinated soap (or Caffeine can kill your creativity!)

This has nothing to do with software development, but seems to cool to left it uncommented: Caffeinated soap!
Feeling too sleepy in the morning and need an extra kick?
In a hurry and without time to shower AND have your morning coffee?
This looks more practical than getting in the shower with your favorite coffee mug:
you will absorb the caffeine through your skin while showering!
(ok, maybe it has something to do with software, it comes from ThinkGeek, and most of the it workers I know are totally hooked up on coffee… myself included)
But use it with caution, as caffeine hurts your creativity!
Yes, my friends, that wonderful black beverage, your companion of many lines of code, is not your best friend when you need to innovate… looks like creativity is associated with alpha brain waves, but the alertness state provided by coffee is associated with beta brain waves (focus, high attention), so when you need to create a solution, leave the coffee aside (or drink the bare minimum to keep you awake)
BTW music seems to have a similar “creativity killing effect”, but that is because listening to music occupies your right brain (the one you need to be creative!). Maybe is all pseudo-science, but if you’re drinking coffee while listening to music, don’t expect to have your “eureka” moment… consider yourself warned!

RUP and risk management

I must admit that I like the Unified Process. The more non-trivial the project is, the more I think is applicable.
Typically, RUP is presented as a use-case driven, architecture first, iterative-incremental process divided in four phases: inception, elaboration, construction, and transition.
Somehow, using a manufacturing metaphor (I know, I know... usually are the worst ones, and can't go too far), the project can be divided into 2 major stages: "engineering" (inception and elaboration) and "production" (construction and transition).
The good thing is "engineering" aims to reduce significantly the risk level of the project. The biggest uncertainties at the beginning of a project are usually related to requirements (and scope) or technical ones, and they have a big impact because they’re the major sources of cost and time overruns. The traditional approach like the “waterfall” process is to pinpoint all the requirements and then complete the design to the detail (what the “agilists” call “Big Requirements Up Front” and “Big Design Up Front”). I will not beat the “Waterfall” straw man, it has its niche (albeit a lot smaller than most people think). Other option is ignore them and hope that the team is “agile” enough to respond to the risks when they materialize.
In the case of RUP, there’s an explicit intention to “defuse” those risks, by exposing and validating the assumptions as soon as possible:

• the inception phase main goal is to discover what it should be done (usually identifying most of the use cases, and detailing the most critical ones)
• the elaboration phase main goal is to define how it should be done, by defining the architecture of the system (based on the critical use cases)

After those phases are completed, you will have the architecture of the system, feedback from the most critical use cases, a clear view of the scope, and no technical surprises awaiting. At this point you should be able to have an accurate estimation of the total project effort, and the total risk exposure of the project should be significantly lower...