HYXT Blog

we produce valuable software for K12.
clock September 28, 2009 16:13 by author Sky Jia (贾超)

Just a quick reminder for myself

It is ok if something is complex so long as it is not complicated.

complex: composed of many interconnected parts; compound; composite

complicated: difficult to analyze or understand

Many problems require complexity to solve. Calculating the discounted value for a 30 year financial instrument using a predicted rate model with a monthly granularity requires a lot of work. You have to generate the rate model, calculate the cash flows from the instrument, then apply the discount to the flows. If this seems simple to you its because you understand the reasons behind each one of these steps.

I don't think any problem requires 'complicatedness' in order to be solved. This is like the reoccuring geek joke, "Well we could call the RateManager and then send the results in a JSON document in an email to the InstumentClass that then faxes the ... and finally a suite of monkeys types the result on your screen". Does your problem need that kind of solution?

Anyways, nothing new, just a note to me.


clock September 16, 2009 23:58 by author Sky Jia (贾超)

clock April 14, 2009 13:54 by author Sky Jia (贾超)

According to the Cambridge Dictionary an apprentice is "someone who works for an expert to learn a particular skill or job". Merriam Webster says: "one who is learning by practical experience under skilled workers a trade, art, or calling". Uncle Bob Martin recently wrote about his experience with apprentices and what he considers key to progressing from apprentice to journeyman.

He describes two hypothetical apprentices: Sam, a developer who has apprenticed with the same master and had the same year fifteen years in a row. The other, Jasmine has changed jobs (and therefore masters) a number of times - growing her skills along the way. The following diagram illustrates the difference in their progress.

Bob’s point is that Sam, who has never changed masters, will always be a student and his growth is limited. Whereas Jasmine, who’s path has been varied,  really is a journeyman – travelling from master to master learning new things from each. Eventually Jasmine herself can become a master.

One commenter JMiller suggests that with a large enough company that you don’t need to leave your employer to change masters companies the size of Google or Microsoft, etc.

Corey Haines points out that while there are companies that are large enough to support Journeyman tours inside the company, none that he knows encourage it.

From her experience at Tektronix, Rebecca Wirfs-Brock remarks: “To me, moving around in the same company is roughly equivalent to changing employers, especially if the company is big enough…and I did several job shifts in my 13 years at Tektronix.”

Corey Haines is starting to have some ideas about how one transitions from apprentice to journeyman:

During the apprentice phase, a person is busy learning. They are practicing specific techniques, rigorously applying rules and procedures. Over time, having been influenced by many mentors, an apprentice starts to develop their own toolbox, the set of practices that they systematically apply. These practices form a basis for further development, a core that an apprentice can build upon.

Paul reports that in the UK companies use a similar approach hiring and training mechanical apprentices. After 6-12 months the apprenticeship is complete and people often move on somewhere else in the industry. Even though the company may not retain that person they benefit as they have a larger pool of well trained people to hire from in the future.


clock February 4, 2009 18:22 by author Sky Jia (贾超)

The software/enterprise architect job is an important one. The duties of an architect are numerous and require specific leadership, communication and technical skills to be fulfilled.

In a recent post, Gabriel Morgan wrote about the qualities of an enterprise software architect starting from Daniel Goleman's Emotional Intelligence (EI) abilities: Self-Awareness, Self-Management, Social Awareness and Relationship Management.

Self-Awareness

  • Emotional self-awareness
  • Accurate self-assessment

Self-Management

  • Self-control
  • Transparency
  • Adaptability
  • Achievement
  • Initiative
  • Optimism

Social Awareness

  •     Empathy
  •     Organizational awareness
  •     Service

Relationship Management

  •     Inspiration
  •     Influence
  •     Developing others
  •     Change catalyst
  •     Conflict management
  •     Teamwork and collaboration

The Software Engineering Institute has collected a large number of opinions regarding the duties, the skills and the knowledge of a software architect as seen by various software engineers. A few of the opinions regarding an architect’s required skills are:

David Cornish (Technical Architect, JPMorgan, London, UK):

Strong communication with both technical and business teams 
Strong design experience and technical knowledge 
Analytical and 'joined-up' thinking 
Conflict resolution

Theo Gantos (Consultant, TEKA, Flint, MI, USA):

A renaissance person. Consulting, diplomacy, organization, conceptualization, abstract thinking, logical reasoning, data modeling skills in several methodologies, ability to self-evaluate and adapt quickly, presentation and communication skills, programming expertise, writing skills, sales skills, charisma, finance and return on investment calculation skills, dealing with difficult and change-resistant people, sense of humor.

Venkatesh Krishnamurthy (Technical Architect, Valtech India, Bangalore, KA, India):

  • Creative
  • An Artist
  • Politician
  • Strong willed
  • Excellent communication skills
  • Excellent presentation skills
  • People person
  • Matured
  • Articulative
  • Courageous to make decisions and stand by it
  • Risk taker
  • Good observer
  • Negotiator

Victor Alejandro Baez Puente (Chief Technology Officer, Grupo Nacional Provincial, Mexico City, DF, Mexico):

  • Experience designing an enterprise application with financial auditing, contract management, enterprise workflow, business process integration, and perhaps asset management components
  • Experience with Service Oriented Architecture (SOA).
  • Experience as a chief architect on inception-to-delivery of J2EE projects.
  • Experience with deploying J2EE rich and/or web client applications in a high-availability, clustered environment
  • Expertise in the Unified Modeling Language (UML) for constructing, and documenting the artifacts of software systems
  • Exemplary general IT knowledge (applications development, testing, deployment, operations, documentation, standards, best practices, security, hardware, networking, OS, DBMS, middleware, etc.)
  • Expertise and experience in lightweight, rapid development, agile methodologies.
  • Experience in estimating and measuring project velocity
  • Experience with interaction with legacy systems and phased application integration
  • Exquisite attention to detail
  • Written, verbal, and diagrammatic communication skills

The examples are numerous. Some put an emphasis on leadership/communicator skills while others take specific technical skills into account. What is your opinion on the skills required of a software/enterprise architect?


clock January 4, 2009 14:04 by author Sky Jia (贾超)

Project Time Management is one of the nine knowledge areas of the Project Management Body of Knowledge (PMBOK). It deals with the definition of activities (what are we going to do), the sequencing of the activities (in what order are we going to do them), and the development and control of the schedule (whenare we going to perform those activities).

Agile Time Management
Over the past couple of weeks I have been trying to find out what the main principles of time management are in the case of agile software development. I was able to distinguish 10 principles so far, and I will present them here for your convenience. With each principle I also include a reference to an online article that (as far as I can tell) nicely describes the ideas behind it. If you don't agree with my list, or if you know some better reference material, feel free to add your thoughts!

1. Use a Definition of "Done"
How? Define what "Done" means and only count the activities that are Done.
Why? Prevent the build-up of hidden tasks ("technical debt") that cost a lot of time to fix down the road.
SeeThe Definition of "Done"

2. Use Timeboxes to Manage Work
How? Set a start- and end date for a collection of activities, and don't allow changes to those dates.
Why? Timeboxes keep people focused on what's most important. Don't lose time to perfectionism.
SeeTime Boxing is an Effective Getting Things Done Strategy

3. Don't Add Slack to Task Estimates
How? Don't use scheduling and buffering of tasks. Add one buffer to the end of the timebox/project.
Why? All safety margins for tasks will be used ("Parkinson's Law" and "Student's Syndrom'").
SeeCritical Chain Scheduling and Buffer Management

4. Defer Decisions
How? Make decisions only at the latest responsible time. "No Decision" is also a decision.
Why? The environment may change, making earlier decisions a waste of time.
SeeReal Options Underlie Agile Practices

5. Reduce Cycle Time
How? Iterative cycles should be as short as possible.
Why? Speed up the learning feedback loop, and decrease the time-to-market.
SeeLean Software Development: Why reduce cycle-time?

6. Keep the Pipeline Short and Thin
How? Limit the amount of work-in-progress, and the number of people working in sequence.
Why? Improve response times, speed up throughput.
SeeManaging the Pipeline

7. Keep the Discipline
How? Prevent expensive rework by doing some processes well, right from the start
Why? Solving problems late in a project is more expensive than following proper rules early.
SeeThe Power of Process

8. Limit Task Switching
How? Prevent unnecessary task switching between projects, and prevent interruptions.
Why? Tasks get completed faster on average, and the human brain is bad at task switching.
SeeHuman Task Switches Considered Harmful

9. Prevent Sustained Overtime
How? Disregard (sustained) overtime as a way to accellerate progress.
Why? Lost productivity, poor quality and bad motivation among team members.
SeeThe Case Against Overtime

10. Separate Urgency from Importance
How? Urgent tasks and important tasks should not be done at the same time.
Why? The important stuff will usually not get done, costing you more time in the long run.
SeeA 10 Second Guide to Smoother Projects: Urgent vs. Important


Search

Calendar

<<  September 2010  >>
SuMoTuWeThFrSa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

Categories

Tags