Getting the latest code from all workspaces can be time consuming, forgetting to do so can cause bigger issues…
So, here is the remedy:
There is a hard coded “d” drive to change the drive and navigate to the code source folders. If your code is on c drive you can just remove it…
I think it will be handy if it has more error handling as a report at the end, but for a quick solution, it is available…
If you can’t find the accountable and responsible people defined, you may find people complaining about
– the number of the emails they receive
– repeating same mistakes
– no central location for documents
simply because you are not learning from your mistakes.
Accountable people normally pay the bill of a mistake, and make sure they are not going to pay it twice. If a process is not in place, people get confused, but if they are really nice people, they will try to keep the system going without looking for an accountable.
Responsible people make sure that next time they have a smart way of doing it, at least by not repeating the same mistakes…
No accountable? No bill?
No responsible? No assigned people?
Some people enjoy this as this is an opportunity that they learn a “different task” each time. The environment is so slippy that they can be “x manager” this week, “y manager” next week. Do they know what “x manager” should do/know/implement? No…
Has their task finished? Yes, not the best one, but they managed to get it working [with silly hours of work]
So, because it is working, some people enjoy; the people suffer plays the nice guy… because they are all nice…
If they want to object/comment/suggest, they are left somewhere up and high …
I have ideas. Many of them actually, every day. Especially when going to sleep and just before waking up I have loads of them, so I write them down in my RTM. Every month or so I clean up this list of ideas and edit, delete, and merge them according my feelings. Some ideas make it through several of these inconsequent selections. Those ideas are the ones I’d like to develop further – inventing a business model for them to make it work. So I start writing up an executive summary of maximum 2 pages according Guy Kawasaki’s blog post and there you go; another idea that needs a business model, team, thinking, investment, etcetera.
At this point I somehow can’t seem to take things forward; shipping it. So far, I have read many management books, “VC recommendations”, and blogs about how to make your business model sustainable, to somehow “fit” into the market you want to conquer. However, all these books don’t do it for me – they all provide too much text (is a 220 page guide still helpful?) and rules of “what to do” (based on the past) and not “how to do it” (better = sustainable). I was missing a strong framework that forces me to make sense of all my loose thoughts, while focusing on the business model itself and the future, learning from past success formulas and proven strategies (we all learn from the past), but without holding on to them too much.
Since last week, I’ve been reading up on Business Model Generation by Alexander Osterwalder (72 page preview here). This book is awesome! I was introduced to Alex by my friend Anne McCrossan about a year ago in regards to Somesso, but I didn’t get the chance to read this book until last week. Alex is a Swiss entrepreneur who teaches systematic approaches to business model innovation. The book is innovative on its own as it’s co-created by 470 other experts (not just by anyone – participants had to pay to join the dialogue). How’s that for innovation?!
This book is really easy to digest and fits well into my “low information diet”, which I wrote about earlier. In short and overseeable sections it provides an overview of the learnings from proven strategies and concepts like “blue oceans” (W. Chan Kim and Renée Mauborgne), “the long tail” and “FREE” (Chris Anderson), multi-sided platforms and open business models. Also the business model canvas is introduced (see below), which is indeed very handy. Thanks Alex and the 470 others who helped publishing this great guide! ”
Post is by Arjen, click here if you want to read the post from the original url.
Stakeholder engagement is an important process to be carried through any project. The involvement and engagement can add value and increase the life of the projects that goes live.
Prince2 [Project Management Framework] suggests a good framework for the process:
1. Identification : Know your target people. Who is going to be affected by this project?
2. Analysis of Profiles: This creates inclusive environment where stakeholders’ points of views, influence power, conflicts, interests and tradeoffs can be elicitated. We can divide this group into 4 in the most basic form:
a. Support or oppose the project
b. Gain or lose as a result of the project delivery
c. See the project as a threat or enhancement to their position
d. Become active supporters or blockers of the project/its progress.
3. Defining strategy: The communication stragety will be defined:
a. For each profile, the method, format and frequency of the communication
b. The message sender and receipent are decided
c. What information will be communicated ?
4. Planning strategy: With the correct communicator, the negotiations’ timing and method will be planned.
5. Engaging stakeholders ( Negotiations and Partnership): Carry out the plan.
6.Checking effectiveness (Monitoring): What are the results?
As the subject gets more popular, and my commercial responsibilities are urging to get the best out of it, I am starting to write a series of blogs for Configuration Management[CM], often interchangeable with Change Management
In his book “Adapting Configuration Management for Agile Teams“, Mario E. Moreira explains it as
the discipline of making changes in a planned and systematic fashion. The ultimate task is the integrity of our artifacts and activities. CM is about identification, organization and control of software to maximize productivity by minimizing mistakes.
According to IEEE , the phases for CM are:
1. Configuration Identification:
Detect Configuration Items (CIs), Name them, Acquire them, and create a baseline
CIs can any product deliverables, corresponding plans, requirements, specifications, design, source code, executable, tools, system information.
2. Configuration Control:
a. Version Controlling: As repository starts its life, it will be changed. For each set of changes, we should know exact version of the source code. Version Controlling Systems give a unique check-in number.
b.Change Controlling: Each request/change has a unique identifier. Through a good Incident Management process [ITIL does help a lot], it is assigned to relevant people, with detailed information about the version of the product referred, its priority, and if it is a subset of another change, the parent change, authorized by a controller.
The good thing about TFS is that Version Controlling and Change Management are nicely coupled, so for each check-in, you (may) have to tell the number of the change request[You may want to read negative parts]. This increases the traceability of the source code.
Build Management: When a set of requirements have been fulfilled, we do build the code, and give a number for the version.
The build process includes
– Branching Strategy: Snuffybear has a good article about the strategies:
Model-1 Small Team Model using Emergency Fix Branches
This strategy is for a team of 5 or less, working from the same repository, for the same project, no need for differentiation of the source code.
Model-2 Medium Team Model using a separate developer and release branch
This is for a development team, doing development and bug fixing with different teams. A branch category is for development, and a branch category is for bug-fixing.
Model-3 Large Team Model using parallel development streams
This is for teams heavily working on new features/projects in addition to the code base.
– Continuous Integration process, which is an immediate response of the health check of the integrity of the code. Any Continuous Integration tool can be configured to do the checks for every/after x number of times of check-in/merge.
c. Release Engineering : The project is tested and we are happy to go live, then the version of the release is published, and LIVE environment gets ready for deployment. Deployment process will be another subject for my blog.
3. Configuration Status Control/Accounting:
Collect the data
Record data in a measurable, meaningful, repeatable way.
4. Configuration Auditing:
Analyse the baseline and processes.
Any comments on the tools/processes you are (un)happy about?
If you have the chance to work for a rapidly growing/blue chip company, and every other year/bi-year, new opportunities appear, you know what the internal interview is. If you have not done so, this article is a still good one to read for normal interviews!
It looks so easy at first to have an internal interview. And if you were in a position where the role was being offered to you, [but of course thay have to see the other candidates..], it looks really like a piece of cake…
Too easy? Anything seems to easy can become a challange, and lots of things can go wrong…Here is the list for the challenges and some tips to make the best out of you.
Unlike normal interviews, there won’t be an agent, talking to you about the company, the interview, and what to expect from the interview.
This does not mean that you should contact the HR department and get more details about the format of the interview, what type of questions to expect.
* They have an idea about you before you go to the interview.
Contact influential people:
Make sure they have a good idea about you. The people who know your performance, successful projects, and talent, may not be the influential people over interviewers. Worse than that, the interviewers may have connections with the people who does not technical backgrounds, does not understand the values you’ve added to the projects, and your talent. So, make sure, you have talked to these influential people before the interview, and get some advice after telling your inspirations and reasons why you are a good match for the position.
You are applying for the same you work for. So, they will not ask the basic questions like “Do you know our company?”, which would be a great advantage on external interviews if you have a clear and complete answer.
The advantage is that you will become from your most relevant tasks, i.e. this company. Show them how confident about your company, your knowledge about organisational functions, as well as projects.
The building/room for interview will not a place you have never seen, people looking at you from the glass windows can be familiar faces.
Before the interview go somewhere else, take a 10 minute. And enter the building as if you were interviewing for the first time. This can cause some anxiety, but will help you to show you are excited, and you can look them from a different perspective.
Characteristics questions will be harder
Be prepared, if you had the chance to be a candidate, other [external] candidates will have probably more technical skills [doubling your years sometimes].
However, do underline that you know the environment, so there is no need for training, learning about company and the culture.
Make sure, you have prepared the answers for the characteristics questions, which will grant them you are the right candidate. Selecting 3 strong&weak characteristic relevant to the job, you need handy examples from your company as well as old ones.
It may not go well, other candidates [as they are selected from hundreds of CVs probably] can be stronger, and better fit for the position. This is not the end of the world, make sure you have a nice half an hour review about your application and why you have failed. Feedbacks will be always useful for yourself, your next application, and understanding their expectations. Do tell them, your motivation will not be less the existing motivation you have, and you value the company and your existing role. You may never know, what is waiting for you around the corner….
Now, I have some time to write about a couple of questions I have received about F#, and their answers.
1. To get a specific element of a tuple :
If we do not want to create variables for the elements that we are not interested in of a tuple, we can use “_” for all other elements, i.e.:
let _, _, valBrand= drinks
which is interpreted into the compiler as we see in the FS Interactive window:
val valBrand : string = “Coca Cola Zero”
2. “namespace” keywords stays as is, and we can have either a module or a type [i.e. C# class] under a namespace. The example would be :
let drinks= (Coke, 0.45, “Coca Cola Zero”)
let _, _, valBrand= drinks
File2: BeverageCalculator.fs [placed under the Drink.fs if they are in the same project.]
let drink= valBrand
So, we can use everything from the first namespace,
Happy F# days!