Management

by Oren Ellenbogen on Agile, Management

Continuous Integration as Quality Reflection

One of the most common question in moving towards Agile Development is “Where should I start from?“. If you’ll ask me, setup a Continuous Integration (aka “CC”) would be the first thing you should start with.


Step 1 (Check for compilation bugs): Code Quality ~= 30%


The CC should be able to identify check-ins to your source control, get the latest source and compile it. The output should be either “green” (Everything compiles successfully with 0 warnings) or “red” (more than one warning or compilation errors). In addition to the fast feedback, the output should also include the files that were changed from the last build (and by whom, so people could know where to look).


The immediate value is priceless. the ability to SEE whether your source-code is stable enough to allow other programmers perform Get Latest and continue their work and the “fail-fast” attitude can save you a lot of time in the long run. It’s important to realize though that even if the code compiles without warnings, it still doesn’t mean that you could count on the quality of the code.


Step 2 (Check for component-based quality): Code Quality ~= 70%


If you can go one extra mile, write a few automated tests (via one of the available XUnit frameworks) for your components. This means that you are able to inject the component’s dependencies from the outside and simulate mini use-cases on component’s level. This step is crucial even if you write those after the code itself was written. Let the CC run them if Step 1 is OK. This should allow you to catch the majority of your bugs (I’ll leave the “how to write good tests” to another post). If all is green, you know that the system behaves as expected, at least to some extent.


This step is not trivial as it requires you to design for testability and invest in proper testing. Don’t let go of this step though, automated tests on this level will make your life much easier. It will take your code one (major) step ahead in “write code that could be changed”. Agile is all about that state of mind.


Step 3 (Check for integration-based quality): Code Quality ~= 80%



Now that you’re components are behaving as expected, you should try to write a few (automated, of course) tests that simulate the entire flow of 2 or more components (DB is a component as well) in the system. As the system grows and more uses cases are added, you should try to improve these tests as they give a solid proof that the SYSTEM works.


Step 4 (Make everything visible): Code Quality ~= 90%


The state & quality of your source control should be visible to the Team and Management as you want to insure IMMEDIATE response time in case someone check-ins a low quality code (on any level). Fixing a failing test three days after the change itself is a bad symptom of low visibility or low perception, by the Team, regarding the importance of the quality of the system.


Step 5 (Automated deployment): Code Quality ~= 95%


After successful build you would like to deploy the latest source on a dedicated environment which the developers could play with before deploying to another (testing?) environment. This won’t be a stable environment, but at least it will give a quick look at the current state of the system – the way customers would see it.


Step 6 (Procedures checking): Code Quality > 95%:


You can add many more checks to the flow, such as Tests Coverage or FxCop. Leave those to the end. From my experience, Time .vs. Value in these features will vary from team to team. You’ll gain much more from investing in Steps 2-3.


 


Semingo CC:


Each developer & manager on our team have a CCTray(the little red circle in the little picture above) which is either Red(source control is damaged), Yellow(Build in action) or Green(Life is sweet). We’re using Cruise Control.Net, CCTray, MSBuild (and TFS plugin) and NUnit to perform all of the above. 


A few teasers:


* Image of Steve Urkel (from the famous Family Matters TV series) is shown for failing build.


* On the right you can find Pasha (with a V sign I’ve added), one of our finest hackers modeling a successful build. You can also notice the 582 green tests (including Integration tests) and 2 changes made by Sagie since the last build.


* Going to NUnit Details, you can get the full details:


 


I had to cut the pictures in order to keep a sane width for the post, but you can get the drift.


btw – Aviel, yet another Semingo hacker add a “Doh!” (Simpson) each time the CC is red on his computer. It can be quite funny (and scary, if fully concentrated on code).

 
by Oren Ellenbogen on Agile, Management

Vision from an ex-software prisoner, Part 1

Too many times in our lives as developers, we feel that in spite of our talent, skills and knowledge we just can’t seem to bootstrap ourselves from the mess we’re in. It reminds me many movies (and the great Prison Break television series) where you see a nice, innocent guy put into jail with a bunch of murderers and rapists. After stabbing a guy in order to prevent from being stabbed, our hero gets into more trouble than he started with. This vicious circle goes on and on so by the end of the movie, you are not sure what he could have done different. His skills, talents and knowledge were thrown away, replaced by the need to survive. In many scenarios in life, I feel like that guy.


Avoiding the (really)poor analogy of un-unit-tested\unmanageable\coupled\you-name-it software to jail, I decided to stand up to the challenge(talk about “What not to do”) raised by my friend, Uri Kalish, and share with you my vision regarding top mistakes I have experienced in the last few years. If it will able 1-N (see, I just had to be all geeky about it, even after talking for a full paragraph on jail and murderers) of you guys & gals to change 1-Z things in your world, this post will worth any future creepy comments I’ll get from real ex-prisoners (what?! there must be some ex-prisoners .Net, Java frustrated coders out there, right?).



  • “Promoting” best coders into solely management positions
    It is the fear of losing someone and the way our community treat one’s status causing this behavior. To make things worse, in most of these scenarios, the company (somehow)feels obliged to let him\her* manage 4-5 people so there is no fat chance he’ll write code in the coming 2-3 years. I believe that this is the top-1 fatal mistake companies do. They are losing their most talented, most efficient programmers without the right adjustment and natural growth by the rest of the team. The way I see it, this is what a Team Leader should be responsible for:

    • Code for at least 60% of his time. Not 20%, not 30% and most definitely not 50%(this will cause him to fall back into 60%-40% manager). Great war leaders were great warriors, always on the front of their men. If you prefer to be left behind(technology speaking), managing from above, you should not be a Team Lead.
    • Get to know your people – what do they like to do after work hours, what are their hobbies, write down their birth-dates so you could buy them something symbolic. Make them feel like home. Spending 10+ hours in the office is more than most of us spend in our home. Notice how a very cheap gesture may change your team’s world – some people like fancy keyboards, some(I’m included) prefer a big LCD screen and others prefer an extra bonus. Let’s say that you invest up to 500$ per person, the ROI is still tremendous(try to think your hourly cost and how fast you’ll return it). People will have everything they need(=want) in their office. Google is famous of hiring the best just because of taking care of the small details.
    • Manage your team’s time – help to set the deadlines per sprint\iteration, but more important – analyze the team’s productivity by picking up time estimations and actual time spent, and perform some calculation via various tools to understand the bottlenecks your team experience. Make them see, make them witness of how they can become more productive with the right set of exercises.
    • Be a mentor by leading the team with daily improvements. Change the way they think, blow their mind with new stuff. Direct them to “home reading” that you know they’ll enjoy. Make them excited! Be a great developer for them.
    • Shield your team members from political business. Make sure no one is interrupting them meeting the deadline.
    • Meet the deadlines. Don’t afraid to speak your mind when things are out of track. Make them see you’ve got what it takes to lead them back to the right path. Tough love may create great developers with the right amount of genuine caring.

         This will allow the Team Leader to remain an efficient programmer and the team grow into the new situation.         
 



  • Big teams
    Team size should never be more than 4, where preferable(IMHO) is 3. We want our Team leaders to write code, remember? Managing more than 2 people other than yourself will make your TL too busy to code. Even worse, big teams will cause team illness:

    • No matter of how much good-will exists in the team, keeping many people in the loop is simply too much overhead. It will wear off your teammates.
    • This will divide the team into smaller “virtual” teams, each one is built around a user story or a complete feature.
    • Now it’s getting hard to know when you’re breaking things for others as no one is really into your teammates code or requirements.
    • This leads us to the most unwanted behavior – no one in these virtual teams is an expert on their domain as the team switch context all the time to meet the big team deadlines. Context switch and lack of domain experts will kill you team. From inside out.

         Keep your teams small. Managers should sync the small teams and keep the eye on the ball for them. This is their skill, their talent.



  • Waste valuable time on the wrong tasks – skills .vs. tasks impediment
    This one really gets me. How many times you’ve been asked to do something you know you shouldn’t have assigned for? Giving a c++ hardcore hacker to write HTML is silly(at best). Now, I can relate to the feeling managers have assigning these tasks  just to keep the deadlines but this shows of lack of creativity rather than good leadership. For example, the c++ hacker will cost around ~X5 then a young talented designer (by young I mean 16 years old cool dude that’s doing it from age 11). Hire someone, even for a few hours a month and let the them do their magic. From some reason, managers never thought about hiring a graphic designer to write hardcore c++ code, right? It will be amazing to measure the ROI you can show your bosses even after 2-3 iterations just by putting the right players in the right positions. The same goes about database, system administrator, (customer)documentations etc. Stop treating someone’s time as equal to someones else time. hardcore multi-threading guru will not enjoy a full day or two of playing with HTML to fit different resolutions. Be creative and make the adjustments! 


I have a lot more rants and tips but I’ll leave it for further posts so be good and stay out of software jail.






[*] – I’m sorry but writing him\her all over the place is plain crazy. You know I’m no sexist ;-)

 
by Oren Ellenbogen on Agile, Management

agile Confidence

Wow, it’s an Agile world we’re living in isn’t it ?


Could you guess how many hits you will get by searching “Good Agile” in google? about 12 million!! “Being Agile”, “Agile principles”, “Agile stories”, “Agile practices”, “Good Agile, “Bad Agile” – millions of books and articles out there for us to reach. Buzzwords addicted as we are, we try it all. We pair programming, we work in short iterations, we drop features early and receive early feedbacks, we combine our developers with our QA guys to create some sort of “Feature Team”, we use cards, backlogs, big boards with colors, we Scrum, we XP. We practice. We succeed. We fail. We try. Still, a lot of people all over the world claim that Agile Development don’t actually work and those methods cause more damage than good. Reading Stevey’s post about Good Agile .vs. Bad Agile made me think about my definition for successful agile development. 


Do you ever seen StarGate? if not, it’s really not too late to buy a DVD and catch up. In this great TV series, SG-1, the “main” team on StarGate, explore the galaxy through a series of Star-Gates, each one located on a different world, which allow them to move from one gate to another through some sort of wormholes that connect the gates together. Their job is to interact with other species, to establish alliances and to acquire new technologies. SG-1 is my definition for an agile team.


Let me introduce you to the team:


jack.jpg


Jack. A confident soldier and the ultimate manager – he will be the first one to take to bullet, always believing in his teammates and letting them do their job with full confidence. Improvise is his nature. His team are his family. He’s the one that make the team glue together.


sam.jpg


Sam. The genius scientist of the bunch. Do you need someone that will write your Java paper for the university in alien dialect? Do you need to make your car a flying ship from two gums and a rope? Rummer has it that she wrote Skype in pure assembly just for the fun in it and that WCF was actually planned by her(Juval Lowey disagree, though). Never says no (I am naughty…) and always do her job in a professional matter, thinking two(thousands) steps ahead(the 100000 alien she killed concur).


daniel.jpg


Daniel. “I can talk 10293740447303^2 languages in 2827349*3 different dialects” guy. If you have a beloved dead uncle whom you’re dying to talk with, page Daniel and he make it happen. Got a book from 1700BC in Chinese that you are really eager to read, he’ll translate it into English in an hour. A passionate guy that manage to calm the team under fire an to make some sense of Jack’s nonsense.


tealc.jpg


Teal’c. The muscles. Teal’c is an alien that joined the team after being slaved to the “gods”(high rank politician with some impressive gun power) in his home-world. He can kill a nation and shave simultaneously. Brave warrior that brings the confidence the team requires during hard times. If you are an AC Milan fan as I am, he is kind of Gatuso – you thank the lord that he’s on your team.



You know why SG-1 is the ultimate agile team? because of the people in it and the way the complete each other. See, you can learn the tactics, get the right tools but without the right men in the right position, you are as good as dead. From my experience, there are bunch of actions you can do to make your development process as agile as possible:



  • Invest time in developing inner tools for your workers. You need tools to help you code(good IDE), to control your source, to set up a Continues Integration environment, to perform Daily Builds, automatic Unit Testing and Code Coverage, to run automatic UI and Sanity tests. You will want to easily create setup files and deploy them on various testing environments all in a single click. You want fast feedback that your product is stable each and every day.
  • Challenge your people on daily basis. Pair them together on tasks that they can teach&learn from each other.
  • Give your team members the “small” stuff they need (bigger space, another screen, better chair, more food, whatever!).
  • Praise your workers. Glorify them. If they give their best – they deserve that.
  • Treat each and every one differently.
  • Hire the best people and the best people only. yes, it is worth it. one superstar developer is better than 5 mediocre ones. Don’t believe any book or any poor manager that claims otherwise. Hack, don’t trust my words, what do I know anyway? Instead, let’s all read 100 books of XP and Scrum, miss the deadlines, release crapy code and hate our jobs. We can always blame the management. Superstar developers will build tools that can replace 10 mediocre programmers, so let them do it and give them the stage they need. Superstar developers make your company a place worth working for. Best people bring the best with them. Now, isn’t it worth paying some extra for those guys? Don’t worry, you will get your $$$ back, I promise.

So agile, in my book, is the confidence you have in your teammates and the greatness of your people and your tools. Without the best people, don’t bother doing the rest. at least don’t expect for “agile” development. The best you’ll get will be Agile Development and that’s suck isn’t it?

 
by Oren Ellenbogen on Management

Finding the most suitable man for the job

I’m reading a fantastic management book: “First, Break All The Rules” by Marcus Buckingham and Curt Coffman. There were few paragraphs which really made me think about the way I’m interviewing people when our company look for candidates.


“ Managers look at “lower-level” roles like housekeeping or out-bound telemarketing and wonder, “How could anyone want to do that job ? That job must be so demoralizing.” “


“ Let’s take hotel housekeepers as an example. Most of us haven’t spent much time mulling over the details of house-keeping. But consider, for a moment, what hotel housekeepers do and how often they have to do it. Put yourself in their shoes. Okay. Two things might have occurred to you: first, that this is an easy job anyone with a modicum of responsibility can do; and second, that this is a terrible job that everyone, including housekeepers, must hate to do. If this thought crossed your mind, then you would be wrong on both counts.We shouldn’t devalue housekeepers. Anyone can probable clean a hotel room once in a while, but great housekeepers are special. “


“ “How do you know if a room is clean?” we asked them (the housekeepers). They said that the last thing they did before leaving a room was to lie on the guest’s bed and turn on the ceiling fan.
“Why?”
“Because”, they explained, “that is the first thing that a guest will do after a long day out. They will walk into the room, flop down on the bed, and turn on the fan. If dust comes off the top of the fan, then no matter how sparkling clean the rest of the room was, the guest might think it was as dirty as the top of the fan. “



Does it ring a bell? how many times we think that maintaining code is a job that any mediocre programmer can do but developing infrastructures requires a superstar programmer. I guess that we all do in some point of our lives. The truth is that those tasks will be performed in a productive manner according to the person’s talents. If the person is passionate about understanding how current things work just so he could fix a leaking class in the system he’ll probably be very good in maintaining applications (this is the same talent that will make a superstar plummer). If the person passion is to know how the entire framework works, he love to read about the small details and he loves to develop everything from scratch (at least at first), he’ll probably be a great infrastructures developer but poor at maintenance.


As an interviewer, how many times are you interviewing people just to see if they’re good programmers in general. Let’s assume that you’re looking for a programmer for your existing team. “On the one hand, her analytic thinking is excellent, she’s familiar with the technology, she can handle problems by herself and she can find her path in a pile of documents. On the other hand, she looks kind of a “cold” person, which can be problematic in our very bound-together team; But hack, I can teach her how to be “wormer” so she could fit it. what are we waiting for?! she’s an excellent programmer, let’s hire her !!”


Do you really think you can change a person that much ? would she be able to express her full potential in your team ? I guess it’s possible, but not likely. What about your other teammates ? Will they be more productive with her in the team ? I guess that probably not.


My point is that you should consider the talents the candidate should posses before considering the skills and experience you’re looking for. Skills can be taught and upgraded, knowledge can be transfered, experience is only a matter of time. Talent is what we born with and what makes us unique. You can’t teach someone to be a positive guy or a code-passionate person (or any other talent, for that matter), but you can certainly place him in the right spot so he could make the most of his *existing* talents.

 
by Oren Ellenbogen on Life, Management

So when is it a good time to develop infrastructures ?!

Today I sat with Moran after he “paged” me. He reviewed some code of one of our applications and he saw some things he thought he could make better. It was one of those classic “Hey! it should be a single service which every one of our applications will use!”. Step after step he made the required refactoring and some elegant API took shape. The improvement was in magnitude but I still thought that the API should be quite different before making it “public” and placing it in our infrastructure. But, and that’s a big but, the guys that develop the specific application needed the class and Moran was required to help in another project.


Should Moran take the opportunity to invest some time in this API? Should I help him through? We can talk about services, about providers, about extendability. We can play with code just to see how the API will look like. We can play with ideas, learn from each other, share our experience. We can share with others, we can send some quick “API tests” to get some feedbacks.


The process of developing the basics for our applications should be *long*. It should allow space for errors. The margins should be wide enough to let us experience, to learn from our mistakes, to discuss, to make Design Reviews, To Prototyping and throwing it all to the garbage 2 days later. It’s all OK.


But maybe this is not the right time for games. Maybe Moran should make it work somehow and carry on to the next project ? After all, the next project’s deadline is near(like always) and we need to join forces just to keep it up. Hey! we get paid to reach deadlines, to make it happen while keeping the quality at high level. The deadline is sacred. I truly believe that a good team will deliver on time even on the expense of features or well-known but low prioritized bugs.


On the one hand, I know that developing small to medium applications (0.5-2 human years) almost never allow you to invest the required amount of time in the basics. On the other hand, I also know that developing applications at work and infrastructures at home is not the answer for long terms. The process is short. No errors are allowed. There is almost no Design Reviews. Does it mean that the results of “home infrastructures” will be poor ? of course not, but the experience, the ability to break our requirements to programmer stories, to exchange ideas, to grow – is lost. The funniest part is that developing small application without a solid infrastructure turns into medium-large application. I guess it’s the egg-chicken paradox.


The best I can do is to tell the reality from my perspective. My reality is that there is never time(well, that depends on the urgency and the magnitude of the application), and keeping with my expectations makes me perform the global thinking and implementation at home. This is the only time that I actually “have the time”. Investing my time in developing some required infrastructure can save my guys at work a significant amount of work. Still, putting the effort on developing infrastructure during work hours will come on the expense of developing user stories, mentoring, guiding, consulting, talking with our customers. I guess that I still don’t know my place. I’m a good developer, I would like to think, and coding some really interesting delegates-based infrastructure or some neat OOP solution are those treats I can’t live without. Still, leading projects, make sure everything ticks and the quality is high is a challenge I love to face in my every-day work; Above all – seeing my guys getting to the next step and helping them in this journey is the main reason I’m doing what I’m doing. I want to be the best I can be for my team and yet make an influence in the way we work via developing some solid infrastructures. My gut feeling is that I need to get better. I feel that I can and should be a lot better as a manager and a programmer but It is still very hard for me to decide how and where to invest my time.


This issue keeps me awake at nights “lately”(last 6 months or so).



Where do you put the line ? How do you decide to invest your time in programming on the expense of managing and vice versa ? When do you think it’ss appropriate to invest additional hour\day\month to something you believe in ? Do you have some rules of thumb ?

 
by Oren Ellenbogen on Management

Working on crazy code – you should know when to stop

Reading Oren Eini’s post & comments about How to tell that this is not production code made me nervous. I don’t know why but for 10 long-enough seconds my eyes twinkled and I managed to pull 5 buttons from my keyboard.


Due to the fact that I know Oren’s character from talking to him quite a bit after my lecture(delegates&anonymous mothods), I have the feeling that he codes-for-fun instead of coding-to-succeed, and he really pushes it sometimes. I can’t say that I’m no sinner, but I think that during working hours, you should use your team’s time in a wiser manner.


You should code with purpose. This purpose should be with one stand to your project deadlines, people quality, maintainability, efficiency, company’s goals etc. This is code-to-succeed in my book.


I wrote this comment down as I’m currently responsible for several applications with some code that actually made me think that this code which “should never be production” made its way into production. It’s even worse, the knowledge of how and why this code behaves the way it does is *lost*. The people who wrote it are no longer here and I’m stuck with code that shouldn’t exists. Oh yes, I almost forgot, this code has numerous bugs and yep, I will have to play along with this dark magic voodoo and get it to work.


One sentence (from Eini’s comments) really got me anemic for couple of seconds:
“We are going to try to explain it tomorrow to another developer, who is going to maintain it, and we will see if he likes it or not.”

This is *unacceptable*. You know that you’re doing some dark magic, you know that this is a disaster waiting to happen and yet you move forward. Let’s say that this poor fellow got the idea, what happens if he quit and a new programmer will have to take care of *your* code ? Who says that you’ll be there to hold his hand ? Who says that he will “like” it ? You must know when to stop…



Wait a minute, hold on, you got me all wrong here !


I’m all about creativity and enthusiasm(!!!!), especially during work time, but the above is just a bad practice and not an excuse. Does that mean you can’t code things you know you’ll have to change later on or even throw them to the garbage ??
Hell no ! this is exactly why you can prototype your solutions if required. Just don’t forget to throw the prototype to the garbage and start all over again with the good insights you have acquired during the process.

 
by Oren Ellenbogen on Management

Bug life cycle – in the eyes of a Programmer

We are working pretty tight with our QA department. Yes, we have some well-documented work procedures but some times I feel that they are too well-documented. After all, we are lazy; We want something easy to see, easy to read & easy to do.


I thought it will be better to document our relations (Development team with QA) in a simple flow diagram:
Bug life cycle – in the eyes of a programmer.ppt (55.5 KB)

update:


I’ve added a step: what should I (the programmer) do if I can’t reproduce the bug ?
Thanks Shani.


Maybe it will help you as well.