The Software Craftsmanship North America conference started today with a keynote by Bob Martin on the failure of state and rise of functional programming. The summary is that maintaining state is getting difficult with multi-core processors and software distribution, and functional programming provides a more disciplined generally less problematic approach to utilizing the extra concurrent/distributed processing power. Although functional programming was invented around 1957, it is finally feasible given the great amounts of memory and CPU cores available to us for cheap today. He ended the talk by mentioning the idea of thinking of everything as a function of time, including database transactions, thus potentially making relational databases obsolete as data is then stored as an initial state and a series of events across time. This prevents side effects as you never modify state, you just append a new data change event. So, to retrieve the state at any point in time, you just apply the change events up to that point, and have the required data as the output result of a function. The best example of that is source code management systems that developers rely on daily to protect their code, like Git.
The next talk was given by Doug Bradbury about how developers are "made to make" software. It summed up to people liking to make things in collaboration with others, often people from different disciplines coming together in order to succeed and achieve their goal.
The third talk is given by Doctor Norton (Michael Norton) titled "Training Software Professionals: Just what the doctor ordered."
During lunch, I had a couple of very interesting conversations.
One was about how the success of software development does not just depend on the developer skills with technology and process, yet also the soundness of the business plan, commitment of the team, openness of management for feedback, involvement of customer and users with requirements gathering and understanding, and other factors. However, people tend to forget all these factors and assume that if a project does not achieve success, then "Agile failed" or the team is not skilled instead of honestly looking holistically at all the factors involved and learning from them instead of blaming.
The other conversation was about Closure, its uses, and whether it will ever be a mainstream front-end development platform or if it will be just a more optimized language for back-end development that takes advantage of multi-cores and distributed systems, while leaving OO languages for the front-end since they closely match the way people think about business domains. A reference was thrown about Deam Wampler mentioning this idea recently, and it seems to make sense, but I would have to gain more experience in functional programming before I can make my own conclusion.
Dave lead an apprenticeship panel consisting of two apprentices from Obtiva (Nate and Ethan) and two from 8th Light (Eric and Colin). Each apprentice introduced themselves and then talked a bit about their apprenticeship. 8th light folks normally had a main mentor. Obtivians often rotated with multiple mentors. At 8th light, they used to have a 3-month limit apprenticeship, but now it's more open ended. At Obtiva, apprentices had to meet a checklist and check-points to graduate.
Apprentices gave this advise to programmers:
-Ask as many questions as possible
-Pay attention to the answers
-Do your homework after getting the answers
-Learn theory and apply, don't just stick to one side
-Pair with as many people as possible
-Don't be afraid to suck while learning
Colin has a background in music and compared the music ethic to the programming ethic as far as practicing hard and learning on the job (during performances with music).
Someone from the audience asked if apprentices ever voiced disagreements of opinion and whether they stick to their opinion or not. One of the apprentices answered by saying he often holds back his opinion until he understood the opposite idea of the other person. Another said he voiced disagreements without pushing too hard as he cared about not tearing the team apart. In any case, all agreed that it is good to voice disagreements in a friendly way though for the benefit of both people in a pair.
Apprentices tend to find themselves wanting to help others learn by learning themselves. They recommend pairing as a two-way learning technique, not just one way.
It is important to balance teaching and learning, and it is a learning oriented exercise.
Someone in the audience asked what's it worth to go through apprenticeship.
One apprentice said he would trade his 6 months of apprenticeship for his 3 years and a half of college.
A couple of people asked about co-op (interning) vs apprenticeship. The difference cited by apprentices was that apprenticeship has the expectation of getting a job afterward.
Apprenticeship program recommendations mentioned were "Set expectations and give more feedback. "
I gave a lightning talk, titled "Software Craftsmanship vs Software Engineering".
Saw Randori with the stars, which was a pair-rotation session between a number of programming stars such as Bob Martin, Ken Auers, Corey Haines, and Chad Fowler.
Ken Auers next gave a a great talk about entrepreneurship, "Lean Craftsmanship vs "Corporate" Craftsmanship"
-It's all about getting/giving value
-Identify Exploration needs and constrain them
Not a spec
no fixed price contract
not cheaper coders or designers
Find the price first.
What is your budget?
Cost of communication is The biggest cost of a software project.
Covering the cost:
-get really good at dev
-identify simple alternative
-pay attention to what's working and what's nost
-Have cheap people do easy things under CLOSE supervision of someone who knows the difference
Test driven development?
-as good as the tests
-sometimes really hard
Where is the risk?
-how do you mitigate it?
-build vs buy?
Recommend book: The Principles of Beautiful Web Design.
Need to learn something about system admin and ux.
... in progress... will tidy up the post afterward.