Showing posts with label methodology. Show all posts
Showing posts with label methodology. Show all posts

Sunday, 28 April 2013

The pragmatic architect



is obviously use-case-driven

A pragmatic architect is someone that gathers use cases and constraints before thinking solution.

Even more, a pragmatic architect cares about the 'why are we doing this?' (i.e. the underlying business goal, that is too often not clearly explicited and shared). He reviews and confronts any option or action with this initial business objective. He tries to deliver projects that will have impact, not only to ship software.

A pragmatic architect does not confuse architecture with tools and frameworks. He also likes architectures to scream their intentions.



knows there is no such thing as 'absolute truth or architecture'

A pragmatic architect knows that there is no absolute truth or solution. She understands that every choice or trade-off is depending on a context (including human considerations).

A pragmatic architect experiences what she recommends to the others. She stands by her choices with the rest of the team or stakeholders.

A pragmatic architect fosters situations where people can live without her. She tries to setup systems that make people fall into the pit of success.



is also a pragmatic programmer

A pragmatic architect is also a pragmatic programmer and a software craftsman. He really enjoys coding and to improve himself at it. If he could not code during working hours (i.e. the slides and diagrams kingdom), he may contribute to open source projects at home.

As every pragmatic programmer, he likes to script and automate every recurrent and painful things as much as possible. He is obviously a big fan of Continuous Delivery.

A pragmatic architect also understands that Continuous Build is not Continuous Integration.

A pragmatic architect is not only talking about Test Driven Development to every reluctant mate, he tries to show the benefits of TDD as often as possible during concrete pair programming sessions.

A pragmatic architect knows the 9 indispensable rules of debugging, and is always willing to remind them to anyone that may need it. A pragmatic architect is also an ego-less programmer.

A pragmatic architect is capable to discuss the strengths and weakness of Object Oriented Programming or Functional Programming to other mates. He likes to step aside and get perspectives on things, and fundamentally needs to understand the reasons of every choices.

A pragmatic architect knows about patterns and anti-patterns, he values GRASP, GOF and POSA patterns, but also cares about the Capacity and Stability ones. As every software craftsman, he also embraces the SOLID principles. But more than anything else, he likes that things stay as simple as possible.

A pragmatic architect likes abstractions, but is aware of the law of leaky abstractions. He also knows that "the pitfall of dogmatism is inherent in any effort of abstraction".

A pragmatic architect has lots of ideas, but he likes nothing more than to share and to debate them with others. But mostly to confront his ideas with the real world. Also, a pragmatic architect does not fear to try. He knows that failure is mother of success. And he usually does not put all his eggs in one basket.

A pragmatic architect does not fear risks, he rather mitigates them.



cares to understand the business stakes.

A pragmatic architect is curious, this is one of the reasons why she chosen this job. And even if she's an hardcore technical addict, a pragmatic architect is someone that cares to understand the business stakes.

A pragmatic architect always prioritizes the work according to the value it brings to the project. This is why she usually defers decisions about the choice of frameworks or tools to be used (db for instance)..

A pragmatic architect always asks 'Why?' five times, so that she can find out the real root causes, intentions, or needs behind her interlocutors words.

A pragmatic architect likes to explicit every kind of implicit. She makes everyone to be on the same page. She's even able to ask naive and silly questions she already knew the answer, just for shy people in the room to heard it. She usually ask people to re-phrase things in order to check they have understood what was said.

A pragmatic architect has not only a vision for the project or the IS, but she cares to share it with ALL the stakeholders involved.

A pragmatic architect is an enthusiastic team player. She really enjoys to collaborate with people and teams.

A pragmatic architect understands that Behavior Driven Design (BDD) is not a matter of tools, but a matter of collaboration and communication among various actors (Biz/BA, ops, QA & DEV).

A pragmatic architect is agile, but doesn't feel the need to repeat it to everyone. She is now more concerned about how to scale agility within the organizations, and how to improve current practices.

A pragmatic architect is as capable of putting project's primary focus on the core domain with Domain Driven Design (DDD), that understanding the technical challenges of all technical stacks. She is multilingual (biz, managers, dev, ops,...).

A pragmatic architect understands that we should stop trying to model the real-world, but only what matter to our software usages instead.

A pragmatic architect understands that event sourcing is not only a technique for technical challenges like High Availability, but something that may bring real business added values.



does not guess, he measures.

A pragmatic architect doesn't like early optimizations. A pragmatic architect does not guess, he measures instead.

A pragmatic architect has both network and hardware skills. He knows not only HTTP, but he masters IP, TCP, UDP... He also tries to avoid having too many war stories, by learning from others' experiences. He also knows how multicast is working under the hood, and other stuffs like it's possible to do unicast with UDP, what is false sharing, what every programmer should know about memory etc. A pragmatic architect is able to understand the impacts of route flapping and network routing convergence on the systems we build. He is a real interlocutor for infrastructure guys and network engineers. He can do that because he is dramatically curious, and always willing to discover new things when he heard about it.

A pragmatic architect is a multi-threading expert, and this is why he tries to help people not to play with threads. A pragmatic architect also likes to spot the deadlocks at home, but hates to do that in production.

A pragmatic architect knows about Recovery Oriented Computing (ROC) and builds production ready systems. He tries to minimize the impacts of bugs on the system when they happen, rather than trusting the idea of a world without bug (ha, ha, ha ;-). Thus, he cares to setup some 'what if ...' workshop sessions before going under production, and to deal with exceptions at system integration points within the system he builds.

A pragmatic architect also knows and cares about mechanical sympathy. He also knows -thanks to the CAP theorem- that you can't have your cake (HA) and eat it (Utter Consistency) too! 

A pragmatic architect is still wary of benchmarks. He knows that almost all of them are done under conditions that have no relationship with what's interesting in the real-world.

A pragmatic architect remembers Schrödinger's cat when he profiles systems (and is also wary of heisenbugs).



likes 'easy in, easy out' technologies 

A pragmatic architect hates golden hammers. She constantly tries to avoid having her own ones.

A pragmatic architect likes 'easy in, easy out' technologies. That's kind of logical, cause she naturally does not like strong dependencies and coupling. And this is why she often promotes the hexagonal architecture.

A pragmatic architect is usually wary of frameworks and rather uses libraries. She tries to know when and where the abstractions will leak.

A pragmatic architect has more to propose than layers architecture only. When she proposes a layers architecture, she intentionally knows why, and is able to explain it to her mates.

A pragmatic architect knows various technologies such as LDAP, NTP, RDBMS, NoSQL, etc. She's really curious, and always willing to discover new things or paradigms.

Of course, a pragmatic architect likes, but also animates Brown Bag Lunches!



reads tons of books, but doesn't blindly apply things 'by the book'

A pragmatic architect is open-minded, and curious. He likes to break silos, and thus enjoys reading things on various other disciplines (not only IT).

A pragmatic architect enjoys to step back and raises his head; he's usually good for the job thanks to his systemic mindset.

A pragmatic architect reads tons of books, but he does not apply things 'by the book'.

A pragmatic architect attends to various IT conferences or 'geek' meetups. He's very social, and always willing to share what he has learned to the mates that couldn't attend those events. He then  spreads the words via twitter, blogs, mails, presentations, coffee breaks, etc.

A pragmatic architect may use acronyms (when he's tired ;-) ; but is always willing to explain their meaning when he sees question tags in the eyes of his interlocutors. He cares about how people receive and understand his words and messages. Thus, he's able to use tricks to re-focus his interlocutors on the core objectives when they diverge.

I already told you, but a pragmatic architect likes simplicity.

A pragmatic architect is aware of the power of humor to communicate with others (except within this current post ;-P


has no IT religion

A pragmatic architect has no IT religion and is not dogmatic. He doesn't care stupid debates like java vs. NET, etc. He's able to think out of the box, and adapts to contexts and people that will implement the systems.

A pragmatic architect cares about others point of views.

A pragmatic architect is able to convince others with a crystal-clear speech. 


But above all, a Pragmatic architect is able to adapt his positions and to challenge himself. 



Last update: November 16th 2013

Thursday, 28 March 2013

The 10 commandments of Egoless Programming


Thanks to my friend dupdob, I've just read the excellent post on kitchensoap's blog: on being a senior engineer.

This must-read-post includes the excellent 10 commandments of Egoless Programming, apparently found on @wyattdanger's blog post (on receiving advice from his dad). Simply Awesome...

  1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
  2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
  3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
  4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
  5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
  6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
  7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.
  9. Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.
  10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

Friday, 1 July 2011

Continuous delivery at Facebook

Chuck Rossi is explaining in a video how the Release management is handled at Facebook; it allows them to push daily updates to their site without production outage or service interruption.  This video is very informative and the announced KPIs are very impressive...

watch the video here

While we are talking about release management, I also highly recommand you to dig into the "continuous delivery" book and blogs of Jez Humble and Dave Farley.

Release management is definitively not only about process and tools; it is about changing our culture.

Tuesday, 28 June 2011

Handle your technical debt with SQALE!

You should try SQALE; a generic, language and tools independent method for assessing the quality of source code.

In a nutshell, SQALE aims to manage the Technical debt within your projects; its classification allows you to analyze the impact of the debt and to define the priority of code refactoring/remediation activities. SQALE is also pragmatic and result-oriented: it is a requirement model and not a set of best practices to implement. Based on this requirement model, SQALE will also allow you to produce ratings for all your projects (from A to E).

Even if SQALE is tool independent, the method target for an automated implementation and you can already find some existing concrete solutions (see the SQALE plugin for SONAR for instance).

You should definitively have a look on SQALE.

Thursday, 10 March 2011

'REWORK': a must read by the founders of 37signals

'Meetings are toxic', 'Don't be a hero', 'Fire the workaholics', 'Interruption is the enemy of productivity', 'Build an audience', 'Good enough is fine', 'Go to sleep', 'Pick a fight', 'Planning is guessing' ... are some of the topics explained within the 37signals founders work manifesto.

This irreverent, but very concrete and clever book is definitely a must read.
It tastes like 'The Pragmatic Programmer' manifesto, but applied to the company level.

Saturday, 6 November 2010

The 9 indispensable DEBUGGING RULES

It's been a while since i've posted on this blog (glad to be back ;-)

As I was recently in touch with some young developers that seemed lost when encountering issues with libraries or technologies they just discovered, I thought that it could be interesting to refresh/share a synthesis on the 9 indispensable DEBUGGING RULES of the MUST READ: Debugging—The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (David J. Agans - ©2002)

Ok then, here are the priceless rules:


[quote starts here]

Memorize them. Tape them to your wall. Tape them to all of your walls.

THE 9 DEBUGGING RULES

  1. UNDERSTAND THE SYSTEM
  2. MAKE IT FAIL
  3. QUIT THINKING AND LOOK
  4. DIVIDE AND CONQUER
  5. CHANGE ONE THING AT A TIME
  6. KEEP AN AUDIT TRAIL
  7. CHECK THE PLUG
  8. GET A FRESH VIEW
  9. IF YOU DIDN'T FIX IT, IT AIN'T FIXED

1. UNDERSTAND THE SYSTEM

This is the first rule because it's the most important. Understand?

  • Read the manual. It'll tell you to lubricate the trimmer head on your weed whacker so that the lines don't fuse together.
  • Read everything in depth. The section about the interrupt getting to your microcomputer is buried on page 37.
  • Know the fundamentals. Chain saws are supposed to be loud.
  • Know the road map. Engine speed can be different from tire speed, and the difference is in the transmission.
  • Understand your tools. Know which end of the thermometer is which, and how to use the fancy features on your Glitch−O−Matic logic analyzer.
  • Look up the details. Even Einstein looked up the details. Kneejerk, on the other hand, trusted his memory.

2. MAKE IT FAIL

It seems easy, but if you don't do it, debugging is hard.

  • Do it again. Do it again so you can look at it, so you can focus on the cause, and so you can tell if you fixed it.
  • Start at the beginning. The mechanic needs to know that the car went through the car wash before the windows froze.
  • Stimulate the failure. Spray a hose on that leaky window.
  • But don't simulate the failure. Spray a hose on the leaky window, not on a different, "similar" one.
  • Find the uncontrolled condition that makes it intermittent. Vary everything you can—shake it, rattle it, roll it, and twist it until it shouts.
  • Record everything and find the signature of intermittent bugs. Our bonding system always and only failed on jumbled calls.
  • Don't trust statistics too much. The bonding problem seemed to be related to the time of day, but it was actually the local teenagers tying up the phone lines.
  • Know that "that" can happen. Even the ice cream flavor can matter.
  • Never throw away a debugging tool. A robot paddle might come in handy someday.

3. QUIT THINKING AND LOOK

You can think up thousands of possible reasons for a failure. You can see only the actual cause.

  • See the failure. The senior engineer saw the real failure and was able to find the cause. The junior guys thought they knew what the failure was and fixed something that wasn't broken.
  • See the details. Don't stop when you hear the pump. Go down to the basement and find out which pump.
  • Build instrumentation in. Use source code debuggers, debug logs, status messages, flashing lights, and rotten egg odors.
  • Add instrumentation on. Use analyzers, scopes, meters, metal detectors, electrocardiography machines, and soap bubbles.
  • Don't be afraid to dive in. So it's production software. It's broken, and you'll have to open it up to fix it.
  • Watch out for Heisenberg. Don't let your instruments overwhelm your system.
  • Guess only to focus the search. Go ahead and guess that the memory timing is bad, but look at it before you build a timing fixer.

4. DIVIDE AND CONQUER

It's hard for a bug to keep hiding when its hiding place keeps getting cut in half.

  • Narrow the search with successive approximation. Guess a number from 1 to 100, in seven guesses.
  • Get the range. If the number is 135 and you think the range is 1 to 100, you'll have to widen the range.
  • Determine which side of the bug you are on. If there's goo, the pipe is upstream. If there's no goo, the pipe is downstream.
  • Use easy−to−spot test patterns. Start with clean, clear water so the goo is obvious when it enters the stream.
  • Start with the bad. There are too many good parts to verify. Start where it's broken and work your way back up to the cause.
  • Fix the bugs you know about. Bugs defend and hide one another. Take 'em out as soon as you find 'em.
  • Fix the noise first. Watch for stuff that you know will make the rest of the system go crazy. But don't get carried away on marginal problems or aesthetic changes.

5. CHANGE ONE THING AT A TIME

You need some predictability in your life. Remove the changes that didn't do what you expected. They probably did something you didn't expect.

  • Isolate the key factor. Don't change the watering schedule if you're looking for the effect of the sunlight.
  • Grab the brass bar with both hands. If you try to fix the nuke without knowing what's wrong first, you may have an underwater Chernobyl on your hands.
  • Change one test at a time. I knew my VGA capture phase was broken because nothing else was changing.
  • Compare it with a good one. If the bad ones all have something that the good ones don't, you're onto the problem.
  • Determine what you changed since the last time it worked. My friend had changed the cartridge on the turntable, so that was a good place to start.

6. KEEP AN AUDIT TRAIL

Better yet, don't remember "Keep an Audit Trail." Write down "Keep an Audit Trail."

  • Write down what you did, in what order, and what happened as a result. When did you last drink coffee? When did the headache start?
  • Understand that any detail could be the important one. It had to be a plaid shirt to crash the video chip.
  • Correlate events. "It made a noise for four seconds starting at 21:04:53" is better than "It made a noise."
  • Understand that audit trails for design are also good for testing. Software configuration control tools can tell you which revision introduced the bug.
  • Write it down! No matter how horrible the moment, make a memorandum of it.

7. CHECK THE PLUG

Obvious assumptions are often wrong. And to rub it in, assumption bugs are usually the easiest to fix.

  • Question your assumptions. Are you running the right code? Are you out of gas? Is it plugged in?
  • Start at the beginning. Did you initialize memory properly? Did you squeeze the primer bulb? Did you turn it on?
  • Test the tool. Are you running the right compiler? Is the fuel gauge stuck? Does the meter have a dead battery?

8. GET A FRESH VIEW

You need to take a break and get some coffee, anyway.

  • Ask for fresh insights. Even a dummy can help you see something you didn't see before.
  • Tap expertise. Only the VGA capture vendor could confirm that the phase function was broken.
  • Listen to the voice of experience. It will tell you the dome light wire gets pinched all the time.
  • Know that help is all around you. Coworkers, vendors, the Web, and the bookstore are waiting for you to ask.
  • Don't be proud. Bugs happen. Take pride in getting rid of them, not in getting rid of them by yourself.
  • Report symptoms, not theories. Don't drag a crowd into your rut.
  • Realize that you don't have to be sure. Mention that the shirt was plaid.

9. IF YOU DIDN'T FIX IT, IT AIN'T FIXED

And now that you have all these techniques, there's no excuse for leaving it unfixed.

  • Check that it's really fixed. Don't assume that it was the wires and send that dirty fuel filter back onto the road.
  • Check that it's really your fix that fixed it. "Wubba!" might not be the thing that did the trick.
  • Know that it never just goes away by itself. Make it come back by using the original Make It Fail methods. If you have to ship it, ship it with a trap to catch it when it happens in the field.
  • Fix the cause. Tear out the useless eight−track deck before you burn out another transformer.
  • Fix the process. Don't settle for just cleaning up the oil. Fix the way you design machines.

(David J. Agans - ©2002)

[quote ends here]